Support for Single Sign-on between Mobile SDK and okta web components

[sdc987]

We are in the process of integrating functionality between our mobile App and our website. Our mobile App uses native SDKs for iOS and Android. Our web site uses the Okta component for login. We were able to get a single sign-on working between the iOS native login and a React.JS application, loaded in a webview, without needing the user to login again.

We have been able to successfully perform this on iOS but Android is giving us some issues.

Steps to reproduce:

• Login in using the native iOS SDK.
• Decode the idToken and AccessToken (see the iOS code below).
• Load the login page into a Webview.
• Used the results from the native login to build the JSON structure that is found in the localStorage ‘okta-token-storage’ structure.
• Reload the Webview

Questions

• Is this supported?
• Is there another way to accomplish this that is recommended?
• Below is the iOS and JavaScript code we used to accomplish this.

Thanks

Below is the Swift code for iOS, the JavaScript code for the WebView, and the Kotlin code for Android

`// *****
//iOS code to decode the tokens and setup the JSON structure for the Web site
// *****
let idData = try! OktaOidcStateManager.decodeJWT(idToken);
let accessData = try! OktaOidcStateManager.decodeJWT(accessToken);
let url = idData[“iss”] as! String;
let ver = idData[“ver”] as! Int;
let verString = String(ver)
let authorizeUrl = url + “/v” + verString + “/authorize”
let userInfoUrl = url + “/v” + verString + “/userinfo”
let scopes = (_oktaConfig![“scopes”]! as! String).components(separatedBy: " ")

let aDic: [String: Any] = [
“accessToken”: accessToken,
“expiresAt”: accessData[“exp”]!,
“tokenType”: “Bearer”,
“scopes”: scopes,
“authorizeUrl”:authorizeUrl,
“userinfoUrl”: userInfoUrl
]
let idDic: [String: Any] = [
“idToken”: idToken,
“claims”: idData,
“expiresAt”: idData[“exp”]!,
“scopes”: scopes,
“authorizeUrl”: authorizeUrl,
“issuer”: self._oktaConfig![“issuer”]!,
“clientId”: self._oktaConfig![“clientId”]!
]

let oktaTokendata = [
“accessToken”: aDic,
“idToken”: idDic,
]

return oktaTokendata;
`

`// *******
// This is the JavaScript code that takes the token create from iOS (code above)
// and addd it to the Okta-token-storage key in local Storage in the webview
// Once Saved, a reload allows the webview to connect to our website without having to authenticate
// ******

const data = JSON.stringify(oktaTokenStorage);

return window.localStorage.setItem('okta-token-storage','${data}' );
location.reload(); true;
`

Libraries used:

iOS:
‘OktaAuthSdk’, ‘2.1.0’
‘OktaOidc’, ‘3.5.2’

`// ******
// The Android side is giving us some challenges.
// Not sure if we are retrieve the structore incorrectly
// ****

    var id = OktaIdToken.parseIdToken(_idToken!!)
    var claimsData = id.claims
    val url = claimsData.iss!!
    var userInfo = _userInfo!!
    val authorizeURL = "$url/v${claimsData.ver}/authorize"
    val userInfoUrl = "$url/v${claimsData.ver}/userinfo"
    val scopes = _accessInfo!!.scope.split(" ")

    val scopesArray1 = ArrayList<String>()
    scopes.forEach { scopesArray1.add(it) }

    val accessMap = HashMap<String, Any>()
    accessMap.put("accessToken", _accessToken!!)
    accessMap.put("expiresAt", _accessInfo!!.exp)
    accessMap.put("tokenType", "Bearer")
    accessMap.put("scopes", scopesArray1)
    accessMap.put("authorizeUrl", authorizeURL)
    accessMap.put("userinfoUrl", userInfoUrl)

    val scopesArray2 = ArrayList<String>()
    scopes.forEach { scopesArray2.add(it) }

    val idMap = HashMap<String, Any>()
    idMap.put("idtoken", _idToken!!)
    idMap.put("expiresAt", claimsData.exp)
    idMap.put("scopes", scopesArray2)
    idMap.put("authorizeUrl", authorizeURL)
    idMap.put("issuer", _accessInfo!!.iss!!)
    idMap.put("clientId", _accessInfo!!.clientId)

    var claims = HashMap<String, Any>()
    claims.put("sub", claimsData.sub)
    claims.put("iss", claimsData.iss)
    claims.put("aud", claimsData.aud[0])
    claims.put("iat", claimsData.iat)
    claims.put("exp", claimsData.exp)
    claims.put("jti", claimsData.jti)
    claims.put("partyUUID", userInfo["partyUUID"] as String)
    claims.put("name", claimsData.name)
    claims.put("email", claimsData.email)
    claims.put("preferred_username", claimsData.preferred_username)
    claims.putString("previousLogonDate", userInfo["previousLogonDate"] as String)
    claims.putString("migrationEndDate", userInfo["migrationEndDate"] as String)
    claims.put("ver", claimsData.ver.toInt())
    claims.put("idp", claimsData.idp)
    claims.put("at_hash", claimsData.at_hash)
    claims.put("auth_time", claimsData.auth_time)
    claims.put("nonce", claimsData.nonce)

    val amr = ArrayList<String>()
    claimsData.amr.forEach({ amr.add(it) })
    claims.put("amr", amr)

    idMap.put("claims", claims)

    var all = HashMap<String, Any>()
    all.put("accessToken", accessMap)
    all.put("idToken", idMap)

    data.put("oktaTokenStorage", all)

`
Android libraries:
implementation ‘com.okta.android:oidc-androidx:1.0.13’
implementation ‘com.okta.authn.sdk:okta-authn-sdk-api:1.0.0’
implementation(‘com.okta.authn.sdk:okta-authn-sdk-impl:1.0.0’) {
exclude group: ‘com.okta.sdk’, module: ‘okta-sdk-httpclient’
}
implementation ‘com.okta.sdk:okta-sdk-okhttp:1.5.4’

[FeiChen-okta]

Hi @sdc987 The SDK is using chrome custom tabs so the sessions in WebView are not shared with CCT. The react native library you are using is WebView so SSO functionality can't be achieve without some modifications to the SDK. This is a similar issue found here:

okta/okta-oidc-js#877

[sdc987]

Hi @FeiChen-okta

Sorry for the delay (I was out sick for a few days)

Looking at the post (okta/okta-oidc-js#877 (comment)) and looking at the custom-sign-in code; It seems to indicate we can utilize a standard HTTPs call to endpoint /api/v1/authn, with the username and password, to retrieve a session token. If we capture the return headers and pass them to the Webview, we should be able to manage SSO. Is this assumption correct?

Just a note, we are looking at using Flutter and not RN. Looking at the custom-sign-in, I can build out the Dart code to make the HTTPs calls and migrate the Native Code Package over to a Flutter Channel.

[FeiChen-okta]

Hi @sdc987, yes that is correct. If you can add the cookies to webview. It should work.

[sdc987]

Hi @FeiChen-okta, I will have to check with our security people. Currently the /api/v1/authn is returning a 400 on me. Not sure how our env is setup. Could /api/v1/authn not be enabled? (sorry new to okta)

[FeiChen-okta]

Your okta auth server should have it. You can use the postman collection to verify
https://developer.okta.com/docs/reference/api/authn/

[sdc987]

HI @FeiChen-okta I was able to get our api/authn endpoint working. But passing in the response cookies and headers to the WebView does not seem to authenticate the user.

Here are the steps that I take in code

1. call the endpoint /api/v1/authn with the username and password

2. Retrieve the headers and cookies

3. Add the cookies to the cookieManager

4. call the loadUrl with the url + route to our home page and passing in the headers

results:
After a second or two the url with the login route is displayed.

questions:

• is this the correct approach?

• is there another call me need to make?

• What particular headers and cookies should I make sure are there?

Thanks

Background info:

our website is a SPA developed with React.JS. The login uses the Okta Widget. Here are the nom pages they use.
"@okta/okta-react": "^1.4.0",
"@okta/okta-signin-widget": "4.4.3",

Environment:
Framework: Flutter version 1.22
WebView: flutter_inappwebview version 4.0.0+4
Currently using an iOS Simulator to test

[FeiChen-okta]

Hi @sdc987
Using the sessionToken (obtained from /api/v1/authn) on the authorize endpoint of OIDC should return the header
Set-Cookie: sid=lGj4FPxaG63Wm89TpJnaDF6
Setting this in the android cookie manager should work for webviews. For more information:
https://developer.okta.com/docs/guides/session-cookie/overview/

[sdc987]

Hi @FeiChen-okta

I’m finally making some progress but I just need to get a couple of things clarified on the flow.

On the mobile side (before loading the webview), we should take the following steps

1. Call the endpoint /api/v1/authn with the username and password
2. Retrieve the Session Token from the above call
3. Call the endpoint /oauth2/aus/v1/authorize?
4. Retrieve the header and sid cookie from the above call

This is where I’m not 100% sure of the flow.

Questions:

1. Should I be able to take the header and cookies (specifically the sid cookie) and load the webview with the redirect location from the 302 return from step 3 (the location header has the redirectUrl with the id token parameter)?

2. After that point, on the mobile code side, I would call the Oidc(iOS) and AuthClient (Android) Authenticate method to retrieve the access token for the mobile use?

I do see the sid cookie in postman after step 3. I’m currently trying to figure out why my Dio library in Flutter is not exposing the Cookies. Once I figure that out, I should be in good shape.

Thanks for your help. I haven’t worked with Okta directly before.

[FeiChen-okta]

Hi @sdc987

1. After step 3 once you have set the cookie. You can let the SDK handle all the redirects and code exchange for getting the access token. The access token and idToken should be returned in the callback or you can retrieve it from the sessionClient.getTokens call.

2. Once you have the access token you can use it by calling sessionClient.getTokens. Should not need to call authenticate anymore.

if you want to check if SSO is working you can open a webview with the site that uses okta for login. It should just log you in since the SID is set in the cookie manager from step 3.

[mdeveracoding]

@FeiChen-okta How should the access token and id token be sent? I assume the access token will be sent as a bearer token in the header? Please let me know otherwise. As for the id token .....how should this value be sent into our webview?

[FeiChen-okta]

Hi @mdeveracoding Yes the access token is used as bearer to access any protected resources. The id token and access token should not be sent to the webview. The session id should be set for the webview.

[mdeveracoding]

@FeiChen-okta do you have a sample postman request that will show what should be sent? In my webview, I have tried using the sid value and the correct url to redirect. However after sending the correct sid value as the cookie and after going to the redirect url I'm automatically prompted to login. Another question as well....is there an Okta setup that we must do within our Okta admin tools. If so, is there any documents you can refer me to?

[FeiChen-okta]

Hi @mdeveracoding Yes. The Authentication API documentation contains sample postman collections that you can use for testing.

For setting the session timeout, you can follow the instructions here

[mdeveracoding]

@FeiChen-okta without the use of any SDK such android....can we call the authn and oauth2 endpoints in postman. Then take the redirect url and sid values and login into our amica web application without being prompted for username and password?

[FeiChen-okta]

@mdeveracoding I have not used postman like that before but theoretically it should work. I would like to understand your use case before going further. Are you trying to have a native sign-in experience first, then after the user successfully signed in, you use that session for in-app webviews?

[mdeveracoding]

@FeiChen-okta yes you are correct. We are trying to have a native sign-in experience first, then after a successful sign in we will want to use the session for in-app webviews.

[mdeveracoding]

@FeiChen-okta ....you mentioned this comment from an earlier post in this thread.....the SDK is using chrome custom tabs so the sessions in WebView are not shared with CCT. What do each letter of CCT represent?

[FeiChen-okta]

@mdeveracoding CCT(chrome custom tabs). For your use case, if you don't want to use AuthN SDK then you can call the primary auth endpoint directly and set all the header in cookie manager.

[mdeveracoding]

@FeiChen-okta ....I have created a new application (SPA) within the okta console. In addition, I have downloaded the sample application that comes by default from the Okta console. When I start the sample application provided by Okta and from our my new SPA application.....I get an error of OAuth2 authorization request failure : illegal_redirect_uri_enhanced. Not sure why this is occurring since I'm following all of the Okta instructions to setup a SPA application. Can you assist? Once I have a SPA application working from your templates....I will then create a native mobile application so that I can get SSO to work accordingly. In the meantime, can you assist me with the SPA error that I just mentioned?

[mdeveracoding]

@FeiChen-okta ....in my prototype, I have two applications that are digitally signed for SSO. One app is a SPA and the other is a native mobile. After I login to the mobile app and before routing to a webview....do I call the authorize endpoint using the web app's client Id? Which in turn will hopefully login via SSO to my web application. Thanks for any help.

[FeiChen-okta]

Hi @mdeveracoding

Are you using authn SDK for native sign in or are you using the default chrome custom tabs in the SDK?
If you are using chrome custom tabs, the session should be saved in chrome. You can then use chrome to sign in to your SPA app and it should sign in. You can also use chrome custom tabs in your application to launch the SPA app.

[mdeveracoding]

@FeiChen-okta ....I'm calling the authn endpoints via URL. Then going to the authorize URL endpoint to get the cookies for a webview. But my question was in regards to the clientid....which one do I use? I'm trying to do SSO from your sample react-native-app to your sample react-js sample app.

[mdeveracoding]

@FeiChen-okta ....do you have a sample app that does SSO between a mobile and web app?

[FeiChen-okta]

Hi @mdeveracoding
It sounds like what you are trying to do is webview SSO using react-native. You will have to use react native custom sign in. First sign in using okta-auth-js client then get the cookies from okta-auth-js and set it in react-native-webview. This repository doesn't have a sample for webview SSO since it only support chrome custom tabs. I would suggest posting in the react-native repository to see if they have any samples. I'll check to see if we have any samples.

[mdeveracoding]

@FeiChen-okta ....yes you are correct. I'm using react native custom sign in. Then I'm trying to populate the cookies into my webview. But can't I just call, https://xxxx.okta.com/api/v1/authn to get the sessionToken? Then pass this sessionToken to https://xxxx.okta.com/auth2/v1/authorize (with appropriate params for clientid, nonce, response_type, state, sessionToken, redirect_uri) and get the cookies from this call to pass into my webview?

[JayNewstrom]

Hi @mdeveracoding thanks for reaching out with the questions. Unfortunately this isn't a use case we support right now. While it sounds like the path you're going down has the potential to be fruitful, our react native/oidc-android SDKs weren't designed and tested for the use case you describe. I've added some discovery work to our backlog. We'll keep you in the loop on next steps from our SDK/samples team.

[mdeveracoding]

@JayNewstrom do you have a date to when you will start supporting SSO from mobile to web?

[JayNewstrom]

We don't have dates planned at this time. I'll update this issue when we have more information.

[mdeveracoding]

@JayNewstrom thank you!

[mdeveracoding]

@JayNewstrom any updates?

[JayNewstrom]

No update yet, this is still high on our priority list though. Thanks for your patience!

[mdeveracoding]

@JayNewstrom .....thanks for the quick update and response!

[NikitaAvraimov-okta]

@mdeveracoding we have done some research on the situation and we do not plan such updates in near future. Nonetheless we can think of a solution with the help of a current sdk. If I understood you correctly you want to sign in and then launch a webview without a need to sign in again, is that correct?

[sdc987]

@NikitaAvraimov-okta yes, you are correct. We are looking to login with the current SDK (for Android and iOS) and from there, be able to launch the WebView without the user having to login again to the web site.

[NikitaAvraimov-okta]

I see, I will prepare some code to demonstrate how to achieve it

[sdc987]

@NikitaAvraimov-okta cool. looking forward to seeing a working example. thanks

[NikitaAvraimov-okta]

@sdc987 have you tried setting your tokens hardcoded to a local storage? Structure for 'okta-token-storage':

{
"idToken":{
"value":"j.w.t",
"idToken":"j.w.t",
"claims":{
"sub":"",
"name":"",
"email":"",
"ver":1,
"iss":"https://<your-domain>.okta.com/oauth2/default",
"aud":"",
"iat":1612776601,"exp":1612780201,
"jti":"","amr":["pwd"],
"idp":"",
"nonce":"",
"preferred_username":"",
"auth_time":1612776598,
"at_hash":""},
"expiresAt":1612780201,
"scopes":["openid","profile","email"],
"authorizeUrl":"https://<domain>.okta.com/oauth2/default/v1/authorize",
"issuer":"https://<domain>.okta.com/oauth2/default",
"clientId":"id"},
"accessToken":{
"value":"j.w.t",
"accessToken":"j.w.t",
"expiresAt":1612780200,
"tokenType":"Bearer",
"scopes":["openid","profile","email"],
"authorizeUrl":"https://<domain>.okta.com/oauth2/default/v1/authorize",
"userinfoUrl":"https://<domain>.okta.com/oauth2/default/v1/userinfo"}}

You can check okta-token-storage value after manual authorization both for iOS and android. After that you can check whether you have correct keys\values after retrievement and let me know if you have difficulties obtaining any of them

[sdc987]

@NikitaAvraimov-okta So our original post (sept 29), about using the okta-token-storage, is a valid solution to use for SSO? We were able to get it working on iOS, but we wanted to confirm it was a valid approach before we started utilizing it on Android. We will work on getting a prototype working. Thanks

[NikitaAvraimov-okta]

@sdc987 If you want to make sure that user will not be challenged with sign-in process if he is indeed signed, even if he changed his default browser etc, than manually setting token storage value is your option.

[blwinters]

@sdc987 Were you able to get this working on Android?

[derekpitts28]

I am running into the same issue here. I don't understand how this is not a higher priority issue as this is such a common scenario especially in larger companies.

We need to be able to SSO into a webview from native mobile (iOS and Android). We do not want the user to sign in again. How do we leverage the mobile SDK to transfer authentication data over to the webview to make this work?

It seems like the Android and iOS SDK hide any useful material. The remaining options being that you store the users username and password to be used later on to request a session token. That seems a bit ridiculous. Being able to transfer the authenticated state easily to a web view seems very important.

Could we please get a way to request a new sessionToken without the need of a users credentials when the user is already authenticated?

[JayNewstrom]

This is not a supported platform feature right now. I'm going to close as there is no actionable work to do from the SDK. If this is an important feature to you, please reach out to [email protected] or your customer success manager.

[joel-mbo]

'okta-token-storage','${data}'

We are in the process of integrating functionality between our mobile App and our website. Our mobile App uses native SDKs for iOS and Android. Our web site uses the Okta component for login. We were able to get a single sign-on working between the iOS native login and a React.JS application, loaded in a webview, without needing the user to login again.

We have been able to successfully perform this on iOS but Android is giving us some issues.

Steps to reproduce:

• Login in using the native iOS SDK.
• Decode the idToken and AccessToken (see the iOS code below).
• Load the login page into a Webview.
• Used the results from the native login to build the JSON structure that is found in the localStorage ‘okta-token-storage’ structure.
• Reload the Webview

Questions

• Is this supported?
• Is there another way to accomplish this that is recommended?
• Below is the iOS and JavaScript code we used to accomplish this.

Thanks

Below is the Swift code for iOS, the JavaScript code for the WebView, and the Kotlin code for Android

`// ***** //iOS code to decode the tokens and setup the JSON structure for the Web site // ***** let idData = try! OktaOidcStateManager.decodeJWT(idToken); let accessData = try! OktaOidcStateManager.decodeJWT(accessToken); let url = idData[“iss”] as! String; let ver = idData[“ver”] as! Int; let verString = String(ver) let authorizeUrl = url + “/v” + verString + “/authorize” let userInfoUrl = url + “/v” + verString + “/userinfo” let scopes = (_oktaConfig![“scopes”]! as! String).components(separatedBy: " ")

let aDic: [String: Any] = [ “accessToken”: accessToken, “expiresAt”: accessData[“exp”]!, “tokenType”: “Bearer”, “scopes”: scopes, “authorizeUrl”:authorizeUrl, “userinfoUrl”: userInfoUrl ] let idDic: [String: Any] = [ “idToken”: idToken, “claims”: idData, “expiresAt”: idData[“exp”]!, “scopes”: scopes, “authorizeUrl”: authorizeUrl, “issuer”: self._oktaConfig![“issuer”]!, “clientId”: self._oktaConfig![“clientId”]! ]

let oktaTokendata = [ “accessToken”: aDic, “idToken”: idDic, ]

return oktaTokendata; `

`// ******* // This is the JavaScript code that takes the token create from iOS (code above) // and addd it to the Okta-token-storage key in local Storage in the webview // Once Saved, a reload allows the webview to connect to our website without having to authenticate // ******

const data = JSON.stringify(oktaTokenStorage);

return window.localStorage.setItem('okta-token-storage','${data}' ); location.reload(); true; `

Libraries used:

iOS: ‘OktaAuthSdk’, ‘2.1.0’ ‘OktaOidc’, ‘3.5.2’

`// ****** // The Android side is giving us some challenges. // Not sure if we are retrieve the structore incorrectly // ****

    var id = OktaIdToken.parseIdToken(_idToken!!)
    var claimsData = id.claims
    val url = claimsData.iss!!
    var userInfo = _userInfo!!
    val authorizeURL = "$url/v${claimsData.ver}/authorize"
    val userInfoUrl = "$url/v${claimsData.ver}/userinfo"
    val scopes = _accessInfo!!.scope.split(" ")

    val scopesArray1 = ArrayList<String>()
    scopes.forEach { scopesArray1.add(it) }

    val accessMap = HashMap<String, Any>()
    accessMap.put("accessToken", _accessToken!!)
    accessMap.put("expiresAt", _accessInfo!!.exp)
    accessMap.put("tokenType", "Bearer")
    accessMap.put("scopes", scopesArray1)
    accessMap.put("authorizeUrl", authorizeURL)
    accessMap.put("userinfoUrl", userInfoUrl)

    val scopesArray2 = ArrayList<String>()
    scopes.forEach { scopesArray2.add(it) }

    val idMap = HashMap<String, Any>()
    idMap.put("idtoken", _idToken!!)
    idMap.put("expiresAt", claimsData.exp)
    idMap.put("scopes", scopesArray2)
    idMap.put("authorizeUrl", authorizeURL)
    idMap.put("issuer", _accessInfo!!.iss!!)
    idMap.put("clientId", _accessInfo!!.clientId)

    var claims = HashMap<String, Any>()
    claims.put("sub", claimsData.sub)
    claims.put("iss", claimsData.iss)
    claims.put("aud", claimsData.aud[0])
    claims.put("iat", claimsData.iat)
    claims.put("exp", claimsData.exp)
    claims.put("jti", claimsData.jti)
    claims.put("partyUUID", userInfo["partyUUID"] as String)
    claims.put("name", claimsData.name)
    claims.put("email", claimsData.email)
    claims.put("preferred_username", claimsData.preferred_username)
    claims.putString("previousLogonDate", userInfo["previousLogonDate"] as String)
    claims.putString("migrationEndDate", userInfo["migrationEndDate"] as String)
    claims.put("ver", claimsData.ver.toInt())
    claims.put("idp", claimsData.idp)
    claims.put("at_hash", claimsData.at_hash)
    claims.put("auth_time", claimsData.auth_time)
    claims.put("nonce", claimsData.nonce)

    val amr = ArrayList<String>()
    claimsData.amr.forEach({ amr.add(it) })
    claims.put("amr", amr)

    idMap.put("claims", claims)

    var all = HashMap<String, Any>()
    all.put("accessToken", accessMap)
    all.put("idToken", idMap)

    data.put("oktaTokenStorage", all)

` Android libraries: implementation ‘com.okta.android:oidc-androidx:1.0.13’ implementation ‘com.okta.authn.sdk:okta-authn-sdk-api:1.0.0’ implementation(‘com.okta.authn.sdk:okta-authn-sdk-impl:1.0.0’) { exclude group: ‘com.okta.sdk’, module: ‘okta-sdk-httpclient’ } implementation ‘com.okta.sdk:okta-sdk-okhttp:1.5.4’

Hey @sdc987 , I have a similar requirement in my application. Would it be possible for you to share the complete JS code that you used to inject into the WKWebView ? Thank you!