I am using vue-adal library in my VueJS application to connect to Azure AD.
AD Token valid for 1hr after login.
When my token expires i am unable to renew it from client side.
Is there any way to renew token from client side using VueJS or
Any other alternate approach can be used for this scenario?
Thanks,
Gowtham
Since you are using implicit flow, azure AD will not return refresh token in implicit flow for you to refresh the token. As per this documentation, here is the recommended approach for this.
A JavaScript application has another mechanism at its disposal for
renewing access tokens without repeatedly prompting the user for
credentials. The application can use a hidden iframe to perform new
token requests against the authorization endpoint of Azure AD: as long
as the browser still has an active session (read: has a session
cookie) against the Azure AD domain, the authentication request can
successfully occur without any need for user interaction.
Related
I already made the authentication flow with the Microsoft Graph/Azure AD authentication. Once I get the authenticated user's token I store them in his cookies. To validate the user's token I call the Microsft Graph API resource /me. This does not seem a good approach because basically everytime time a client does a request to my API, he is basically doing 2 requests because my API requests Azure AD for validation.
Is this a good flow?
No, it isn't.
Your front-end should acquire an access token for your API, which the API can verify using its digital signature.
The token will contain some info about the user as well as the app that acquired it.
The way in which the front-end acquires the token depends on the type of application.
Front-end single page apps use implicit grant flow for example.
Do note that you have to specifically ask for an access token for your API.
As long as your back-end is then configured with standard JWT Bearer authentication,
all is handled.
This is done by specifying the authority as your Azure AD tenant (or the common endpoint if it's multi-tenant),
and the standard bits for JWT authentication should download the public keys from Azure AD's metadata endpoint, which it can then use to verify validity of any access token it receives.
You do not have to validate tokens for an api that's not yours (issued to your AppId Uri).
For example, Graph validates the tokens that are sent to it (issued for "https://graph.microsoft.com).
If you build and register in Azure AD an Api of your own (say AppIdUri="https://myapi.mydomain.com"), your clients will request and receive access tokens with aud claim set to "https://myapi.mydomain.com".
The clients themselves don't need to validate the access token issued for your Api But your Api, when it receives those access tokens, has to validate them. The validations, among other things will validate the access token was issued to "https://myapi.mydomain.com".
Try out this sample, to get a good understanding around concepts of token validation.
Is it possible to establish Azure AD SSO/session (with all required cookies) having only Access/ID tokens obtained using ADAL library?
Our scenario is quite similar with one described here:
We have Cordova app with ADAL library as plugin. We managed to authenticate users and get Access/ID tokens using ADAL. Then we initiate SAML SSO between Azure AD and our backend. It works fine the first time user authenticates using ADAL since it's popups microsoft login screen and after successful authentication it establishes a session with Azure AD. But when user logs out our app clears all cookies and next time ADAL gets's tokens from cache and does not provide the login screen which is OK. The problem is that SAML SSO does not work after that since session is gone (no cookies).
I know that ADAL is not quite designed to work with SAML, but maybe there are some dirty or not dirty workarounds to establish session with Azure AD having only access or id tokens?
No, it is not possible.
To get the session cookies, the user must login by themselves.
You can assist the user in logging in to the right account by specifying their AAD tenant id in the authority URI (instead of common), and by specifying login_hint=username#company.com with their user principal name in the authorization call as an extra query parameter.
They should then only need to enter their password (+ MFA etc.)
I have a JWT token which is generated client side and stored in session storage. It is passed to ASP.NET WebApi endpoints that are decorated with the Authorize attribute. If a user signs out of my application then I can delete the token and sign the user out of Azure.
However if the user goes to a different Azure site and signs out then the token that is used in my application remains valid (despite the user being signed out.) How can I force WebApi to call back to Azure and revalidate the token on each request?
Thanks,
Joe
Azure AD JWT access tokens are self signed and the payload contains the exp timestamp, datetime until which the token is valid. The relying party application does not communicate with Azure AD to validate the token, instead, it uses the self-signed information.
The only way to log out, as you mention, is to delete the token.
When you log out from Azure AD SSO you only log out of the possibility to create new access tokens, but already issued access tokens will continue to work until they expire.
Try to log out from Azure AD SSO but keep the access token to your application: You will still be able to access it.
So if you want to log out from both applications, you will need to delete access tokens for both applications.
I am trying to revoke a refresh token so that it cannot be used any further to obtain more access tokens via oauth2.
I am using simple-oauth2 nodejs library that wraps the requests to obtain access and refresh tokens. Once I have these tokens, I can use the access token to make graph.microsoft.com calls. When the token expires, I can obtain a new one. This library has a .revoke() method that takes a revoke url. I specify this as http://login.microsoft.com/common/oauth2/v2.0/logout
but the refresh token is still valid.
According to https://support.office.com/en-us/article/Session-timeouts-for-Office-365-37a5c116-5b07-4f70-8333-5b86fd2c3c40?ui=en-US&rs=en-US&ad=US
The Azure Active Directory: "An administrator can apply conditional access policies which restrict access to the resource the user is trying to access."
Is it possible to revoke using oauth2 request? I see this https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oidc
which shows the oauth2 logout url /common/oauth2/v2.0/logout.
Azure Active Directory does not support or provide an endpoint for an application to revoke the refresh tokens. The recommended approach is to clear the token cache on logout to prevent the re-use of the token.
A similar post is here: Revoke a refresh token on Azure AD B2C
You can read more about the policies on token lifetimes of refresh tokens here
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes
I'm trying to set up an Azure Web App to to authenticate with Azure AD and refresh ID Token behind the scenes automatically.
A great blog post helped me understand how the whole thing works:
https://cgillum.tech/2016/03/07/app-service-token-store/
And this guide linked from it helped me set it up:
http://cgillum.tech/2016/03/25/app-service-auth-aad-graph-api/
It seems enabling refresh tokens for Azure AD authentication isn't that simple so as recommended I used the aforementioned guide to set it up as if it were for GraphApi.
The problem I'm having is even after calling the ".auth/refresh" endpoint and then calling the ".auth/me" endpoint, the only token which is refreshed is the Access Token. That token is of no use to me since I use the Id Token when communicating with my backend server (using an "Authorization Bearer" header).
So how do I get the Id Token to refresh as well?
Unfortunately AAD does not support refreshing the ID token. Only the access token can be refreshed. See here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-protocols-oauth-code/#refreshing-the-access-tokens
But even if it could be refreshed, it's more correct to use an access token when authenticating with another service, so I suggest changing your apps to work this way. The claims on the access token and the id_token are very similar so it should not be a very disruptive change.