I am trying to use the accessToken from a custom challenge handler. We want to send that accessToken and token id to an external service. that will validate the token by calling mobile first token validation endpoint.
How to read access token and token ID. In MFP 6.3 we have WL.Client.getLastAccessToken that has been deprecated. Is there any API which read the access token received for a challenge handler.
obtainAccessToken
obtainAccessToken(scope, onSuccess, onFailure)
Obtains an OAuth 2.0 access token from the Worklight server. The token is required in order to send a request to an external server which uses this Worklight authentication method.
Parameters:
scope - Optional. The name of the security test protecting the external resource. If the scope is null, a token for the application's default security test will be obtained.
onSuccess - The success callback. Note that there is no need to parse the response. Instead, use WL.Client.getLastAccessToken(scope) in order to get the last obtained token.
onFailure - The failure callback.
Deprecated:
Since version 7.0
Is there any alternate API in MobileFirst 7.1
Response Data: {"access_token":"eyJqcGsiOnsibW9kIjoiQU0wRGQ3eEFkdjZILXlnTDdyOHFDTGRFLTNJMmtrNDV6Z1p0RGRfcXM4ZnZuWWZkaXFUU1Y0XzJ0Nk9HRzhDVjVDZTQxUE1wSXdtTDQxMFg5SVpudmh4b1lpRmNNU2FPZUlxb2UtckpBMHVadXcyckhoWFozV1ZDZUtlelJWY0NPWXNRTi1tUUswbWZ6NV8zby1ldjBVWXdYa1NPd0JCbDFFaHFJd1ZEd09pZWcySk1HbDBFWHNQWmZrTlpJLUhVNG9NaWktVHJOTHpSV2tNbUx2bTA5aEw1em9zVU5BMTV2ZUNLcGgyV3BtU20yUzYxbkRoSDdnTEVveW1EblRFalBZNUFvaDJpbkktMzZSR1lWTVVVYk80NkNyTlVZdUlvYk9pWGxMekJJaHVJQ3BmVmR4VF94N3N0S1g1QzlCZk1UQjRHa09IUDVjVXY3TnoxZERoSVB1OCIsImV4cCI6IkFRQUIiLCJhbGciOiJSU0EifSwiYWxnIjoiUlMyNTYifQ.eyJpbWYuc2NvcGUiOnsid2xfYW50aVhTUkZSZWFsbSI6eyJleHAiOjE0OTYyNTk0NzEsIm1hbmRhdG9yeSI6dHJ1ZX0sIkN1c3RvbUF1dGhlbnRpY2F0b3JSZWFsbSI6eyJleHAiOjE0OTYyNTk0NzF9LCJ3bF9kaXJlY3RVcGRhdGVSZWFsbSI6eyJleHAiOjE0OTYyNTk0NzAsIm1hbmRhdG9yeSI6dHJ1ZX0sIndsX3JlbW90ZURpc2FibGVSZWFsbSI6eyJleHAiOjE0OTYyNTYxNzAsIm1hbmRhdG9yeSI6dHJ1ZX0sIndsX2RldmljZU5vUHJvdmlzaW9uaW5nUmVhbG0iOnsiZXhwIjoxNDk2MjU5NDcxLCJtYW5kYXRvcnkiOnRydWV9LCJ3bF9hbm9ueW1vdXNVc2VyUmVhbG0iOnsiZXhwIjoxNDk2MjU5NDcwLCJtYW5kYXRvcnkiOnRydWV9fSwiaXNzIjoiaHR0cDpcL1wvcHJhc2FubmFzLW1icC5tZXRsaWZlLmNvbToxMDA4MFwvQ3VzdG9tQXV0aFwvYXV0aG9yaXphdGlvblwvIiwiZXhwIjoxNDk2MjU5NDcxLCJwcm4iOiI0ODE4YTJkODNkMDE0ZDkxNzcwNTdmOTc3MGI1OThkOTA5NmUxZmI3In0.qiej5KRanOOx_sjdCgdl8cFVLC88_V1yIcAML2GetHEjH8-ORyabJ0Ax0kjgEU5tMgEh6wg7A0LeW9rcZR_A9K5biLEQRJBvqcjKzedmq9DFYB_GluRL0W7pDyOk2ZpRBKQm5FXsxjKKda-yVd_7i7ipfYjMqUWctcloeXelDkPxbfxVxB1X7lyqmihflvE3ir9UG7WkxxbEAtZIUIdMkmmwCoitlTTjKPLjHfihlEJQQEm59jgXuBv2l62nWVG9eoqNnTCuYH3PlpiDK1YyK0ThBZxjAa2pLkOH1myPQRH2e-rfwJlaOit5ZosEm7pwXM2AEnvKNYyhw_2RPAnLVA","scope":"wl_antiXSRFRealm CustomAuthenticatorRealm wl_directUpdateRealm wl_remoteDisableRealm wl_deviceNoProvisioningRealm wl_anonymousUserRealm","id_token":"eyJqcGsiOnsibW9kIjoiQU0wRGQ3eEFkdjZILXlnTDdyOHFDTGRFLTNJMmtrNDV6Z1p0RGRfcXM4ZnZuWWZkaXFUU1Y0XzJ0Nk9HRzhDVjVDZTQxUE1wSXdtTDQxMFg5SVpudmh4b1lpRmNNU2FPZUlxb2UtckpBMHVadXcyckhoWFozV1ZDZUtlelJWY0NPWXNRTi1tUUswbWZ6NV8zby1ldjBVWXdYa1NPd0JCbDFFaHFJd1ZEd09pZWcySk1HbDBFWHNQWmZrTlpJLUhVNG9NaWktVHJOTHpSV2tNbUx2bTA5aEw1em9zVU5BMTV2ZUNLcGgyV3BtU20yUzYxbkRoSDdnTEVveW1EblRFalBZNUFvaDJpbkktMzZSR1lWTVVVYk80NkNyTlVZdUlvYk9pWGxMekJJaHVJQ3BmVmR4VF94N3N0S1g1QzlCZk1UQjRHa09IUDVjVXY3TnoxZERoSVB1OCIsImV4cCI6IkFRQUIiLCJhbGciOiJSU0EifSwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJkZW1vOkN1c3RvbUF1dGhlbnRpY2F0b3JSZWFsbTo0ODE4YTJkODNkMDE0ZDkxNzcwNTdmOTc3MGI1OThkOTA5NmUxZmI3IiwiaW1mLmFuYWx5dGljcyI6eyJlbnZpcm9ubWVudCI6ImlwaG9uZSIsImlkIjoiSHlicmlkQ3VzdG9tQXV0aCIsInZlcnNpb24iOiIxLjAifSwiaW1mLmFwcGxpY2F0aW9uIjp7ImVudmlyb25tZW50IjoiaXBob25lIiwiaWQiOiJIeWJyaWRDdXN0b21BdXRoIiwidmVyc2lvbiI6IjEuMCJ9LCJpbWYuZGV2aWNlIjp7Im9zVmVyc2lvbiI6IjkuMyIsIm1vZGVsIjoiaVBob25lIiwiaWQiOiJCRUU5QjcwMC00NzkwLTRDQzEtOENCOC1GQUExREQwMjk4OTMiLCJwbGF0Zm9ybSI6ImlPUyJ9LCJpbWYudXNlciI6eyJhdXRoQnkiOiJDdXN0b21BdXRoZW50aWNhdG9yUmVhbG0iLCJhdHRyaWJ1dGVzIjoie1wiQXV0aGVudGljYXRpb25EYXRlXCI6XCJNYXkgMzEsIDIwMTcgMjozNzo1MSBQTVwifSIsImlkIjoiZGVtbyJ9LCJpc3MiOiJodHRwOlwvXC9wcmFzYW5uYXMtbWJwLm1ldGxpZmUuY29tOjEwMDgwXC9DdXN0b21BdXRoXC9hdXRob3JpemF0aW9uXC8iLCJleHAiOjE0OTYyNTk0NzEsImlhdCI6MTQ5NjI1NTg3MX0.ojcboxmS-7pQqTx1ebugTuUalbO61_HGmpVSi6_XbIQ_VCknq1zAjRgMeU0NWeaKPHDZiZlEr-nst9EUKzlKvdQNJfDZ-jjF-Nw1IVV0bfy5_YfrDWju3gY5gzNmxi188SydKxDVf6Ncv02YA6SpNU2XaoArrfGnkhmjbEaZUaWj9e8SF9xbMmaNgDfKOQs2WFJZfRY2DdkG1YodVPipxbtD81Bw4rZ-vroAkXZznd9meWmTZx9bxKtNcMqtala8NFvR6hHiLfKZuZno7FjVv26UV8pfHuLed24fHuMAxhD2wLCKfo6ZDarrcWRVZb30tJZ0AD4mGhnV6Y5PxFO7ng","token_type":"bearer","expires_in":3600}
For migrating from 6.3 to 7.1,
Please refer to ibm.com/support/knowledgecenter/SSHS8R_7.1.0/… , I see that you can use WLauthorizationManager.getCachedAuthorizationHeader() available in 7.1
from 7.1 to 8.0 ,
Please refer here Alternate API's for deprecated APIs in 7.1 https://www.ibm.com/support/knowledgecenter/SSHS8R_8.0.0/com.ibm.worklight.upgrade.doc/devref/c_sdk_changes4migration.html
In this particular scenario, https://www.ibm.com/support/knowledgecenter/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/html/refjava-worklight-android-native/html/com/worklight/wlclient/api/WLAuthorizationManager.html has to be used.
Have you tried WLAuthorizationManager.obtainAccessToken(scope) ?
Related
I'm testing authentication for a server based web app.
I think the best way to login the browser is with Implicit Flow to obtain only an id_token via an HTTP POST.
I've configured my OpenIdConnectAuthentiationOptions like:
Scope = OpenIdConnectScope.OpenIdProfile,
ResponseType = OpenIdConnectResponseType.IdToken,
ResponseMode = OpenIdConnectResponseMode.FormPost,
These should be the options to do what I am asking.
When I try to authenticate, I am given the error:
'AADB2C90057: The provided application is not configured to allow the
'OAuth' Implicit flow.
But, I have enabled Implicit Flows in the app registration in Azure AD B2C. However, I specifically am NOT enabling "Access Token," because obviously I am NOT requesting one.
I'm specifically following the instructions to select only "ID tokens," for web apps using hybrid authentication.
If I change the option to ResponseType = OpenIdConnectResponseType.CodeIdToken I have the same issues. Although, I think this response type also requests an Access Code.
If I enable both ID Tokens and Access Tokens, then the app logs in fine. Why do I have to enable "Access Tokens" when I am only requesting an ID Token?
The basis for what I am attempting is described here: https://learn.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-asp-webapp
Please check the Important note from OAuth 2.0 implicit grant flow | Microsoft Docs which is the same doc which can be obtained by clicking 'learn more about tokens.' hyperlink.
NOTE:
Which says we need to check both idtoken and accesstoken to obtain id token or access token or in combination of both, but the response depends on the responseType mentioned in the authentication request (you may read same document further for the details).
i.e.;
You will receive idtoken , if you have given responsetype =id_token
You will receive accesstoken if responseType=token
You will receive code and id token in case of responsetype is
id_token+code
Request an ID token as well or hybrid flow
I'm using ASP.Net Core 6 to build a secured Web API.
HOW I BUILT IT
dotnet new webapi --auth SingleOrg --aad-instance https://login.microsoftonline.com/ --client-id <CLIENT ID> --domain company.onmicrosoft.com --tenant-id <TENANT ID> --calls-graph true -o GraphTestService
APP REGISTRATION OF WEB API
I added a Scope in the Export API "EmployeeRecord.Read"
APP REGISTRATION FOR CLIENT (Public Client)
Added permission for Graph API (User.Read)
Added permission "EmployeeRecord.Read"
HOW I GET TOKEN USING THE CLIENT
I'm using "InteractiveBrowserCredential".
Everything works fine up until the Web service tries to call Graph API. It throws MsalUIRequiredException.
Understandable, since I did not include any graph API permissions when I requested a token.
FINALLY, THE PROBLEM
When I inspect the Bearer token that's returned, it has the "EmployeeRecord.Read" scope. Ok, that's fine. The Web API authorizes it; but the token doesn't have any permissions for Graph API.
When I add a graph API permission to the scopes, I get
AADSTS28000: Provided value for the input parameter scope is not valid because it contains more than one resource. Scope api://<APP URI ID>/EmployeeRecord.Read https://graph.microsoft.com/User.Read offline_access openid profile is not valid.
If I only include the graph API permission, the Web API returns an Unauthorized error.
WHAT I'VE TRIED
In addition to playing with the scopes, I tried adding my client application to the Web API app registration under the "Expose an API / Add A client Application". This made no difference. No difference in token or errors.
You are trying to add scopes for 2 different resource ,the scope parameter cannot be used to specify permissions for multiple resources similar issue .
we recommend you to use MSAL libarry , MSAL will store tokens for you and refresh whenever token is expired. Just call acquireTokenSilent to get an access token silently, and if you get an error, call acquireToken (see details on error handling here: https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-handling-exceptions#msal-for-ios-and-macos-errors)
for more info please check similar issue
Thanks
I Have to implement a push notification service using ASP .Net Core. as obvious choice is to use SignalR Core.
Our platform setup is using Azure App gateway and it is configured to not allow unauthenticated requests.
We have setup WebSockets communication with SignalR.
Under the hood , SignalR Core follows these steps:
POS ../negociate -> OK with hub_token and supported transport
GET (sends Upgrade header and WebSockets token)../Hub?id={hub_token} -? fail
when investigating why the step 2 does not upgrade the connection to a WebSocket connection , I have noticed that the GET request is missing Authorization header. Obviously AG block this request and doesn't even get to the API.
I have tried manually to make a "handshake" with postman.
the above steps :
OK
included Authorization JWT header -> result 101 ,and Fiddler confirm the connection is opened.
I have researched the documentation and found that Authorization headers are not supported.
did anyone tried any workaround ? hen is the next release of the #aspnet/signalr client?
Did you specified the accessTokenFactory?
let connection = new signalR.HubConnectionBuilder()
.withUrl("/myhub", {
accessTokenFactory: () => {
// Get and return the access token.
// This function can return a JavaScript Promise if asynchronous
// logic is required to retrieve the access token.
}
})
.build();
More info here.
so the final resolution is:
that in browsers is a limitation for sending JWT header along with HTTP 101 UPGRADE
I'm integrating Okta to my own IdP server by using Okta's API.
I'm implementing the Authorization code flow by following the steps below:
In my own server, use the /api/v1/authn endpoint to get the sessionToken.
Use the sessionToken to obtain the authorization by calling this endpoint: /oauth2/v1/authorize?client_id=" + clientId + "&sessionToken=" + sessionToken + "&response_type=code&response_mode=query&scope=openid&redirect_uri=" + redirectUrl + "&state=evanyang&nonce="
It's supposed to return a response with status code 302 and with the Location header containing the redirect url as well as the code value.
However, I keep getting a response with status code 200 and without the Location header, with a html body saying "You are using an unsupported browser." and "Javascript is disabled on your browser."
According to the API documentation: http://developer.okta.com/docs/api/resources/oidc.html#authentication-request, the sessionToken parameter is sufficient to do this: An Okta one-time sessionToken. This allows an API-based user login flow (rather than Okta login UI).
Am I missing any extra requirement for getting the authorization code through API? Please help.
Thanks in Advance :)
The Authorization Code grant type and the Authorization endpoint in there are meant to be access through a browser, not a non-browser client.
This issue is caused by obtaining session id between obtaining session token and authorization code. Once the session token is used to get session id, it becomes invalid, which means it cannot be used to get authorization code anymore.
According to Okta, the Authorization Code grant type and the Authorization endpoint and be used through a API-based web app too, as long as the session token is provided in the request: http://developer.okta.com/docs/api/resources/oidc.html#authentication-request. In fact, one can use this script(https://github.com/SohaibAjmal/Okta-OpenId-Scripts) to finish the flow.
I have a test application that accesses two Adapters:
A JavaScript adapter protected by a SecurityTest referencing a realm
A Java adapter with a method protected by an OAuth scope corresponding to that same realm.
If I follow this sequence everything works as expected:
Attempt to access the JS adapter, I get challenged, authenticate, get data.
WL.Client.isUserAuthenticated() and WL.Client.getUserInfo() now behave as expected
Logout using WL.Client.logout()
WL.Client.isUserAuthenticated() now shows I'm not authenticated
A second attempt to access the JS adapter causes another Challenge, as expeccted.
However, with the Java Adapter logout() seems not to behave as expected.
Starting with no session, attempt to access the Java adapter, the challenge happens as expected and I get to my data
I can now access the JS adapter without further challenge and the WL.Client.getUserInfo() calls gives the expected results.
WL.Client.logout() appears to work, in that WL.Client.isUserAuthenticated() now shows I'm not authenticated
But a call to the Java adapter still works without further challenge
A call to the JS adapter does result in a challenge
If I'm running in my browser simulator environment I can destroy the OAuth session by using this command:
localStorage.removeItem("com.worklight.oauth.idtoken")
The question is:
Should the WL.Client.logout() method have destroyed the OAuth session? If not what API should I be using?
With OAuth, logout 'works' differently. See the following user documentation topic (search for "logout"): http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.dev.doc/dev/c_oauth_security_model.html?lang=en
The login/logout API:
The WLClient login/logout API enables a user to
log in to and log out of a specific realm, by updating the server side
security state. However, in the new OAuth-based security model,
security credentials are also kept in the access token on the client
side. The result is that using this API will cause an inconsistent
state, for example, in which the client is logged out of a realm on
the server side but still holds a valid token for that realm on the
client side. To solve this inconsistency, it is recommended to
re-obtain the access token, by using the
obtainAuthorizationHeaderForScope method, after successful login or
logout.
For example, consider a client that passed the security checks for
Realm1 and Realm2, and later calls logout(Realm2). In this case, the
access token on the client would still contain the security
credentials for both Realm1 and Realm2, and the client could use this
token to access protected resources. To refresh the token, that is, to
obtain a token for Realm1 only, the client calls
obtainAuthorizationHeaderForScope without the logged out realm Realm2.
In JavaScript the equivalent call is:
WLAuthorizationManager.obtainAuthorizationHeader("SomeRealm")