We are facing issue on logout from our application. Once we logout then its perfectly fine from browser but if we capture the request from some tools (fidler or burp) and send the request again to server with old cookies and session details give full response. This is only possible through any interceptor tool only. I am using the below code to logout from application:
Session.RemoveAll();
HttpContext.GetOwinContext().Authentication.SignOut(OpenIdConnectAuthenticationDefaults.AuthenticationType,
CookieAuthenticationDefaults.AuthenticationType);
This is happening because access token and refresh tokens issued by Azure AD are not deleted when you initiate the log out from your application. As long as these tokens have not expired, they can be used.
Based on this, access token lifetime is configurable (default I believe is 1 hour) and you should set it based on your needs.
Also, there's a feedback post regarding invalidating tokens: https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/19474918-invalidate-jwt-token. Feel free to upvote this feature.
Related
I am struggling to get access tokens from .net console app context. I am getting them and they work, but they expire too fast.
I checked the other two threads in stackoverflow, in both answers it was stated, that once you get the consent per IK and per user, you don't have to do it anymore. However once I get the bearer token from the return_url and use it to request the access tokens a few minutes after the bearer was obtained, I get response with "error_description:expired_client_token".
So me manually obtaining bearer from the browser in order to set it as a parameter (again manually) in my console app and having the bearer expiration duration just a few minutes doesn't match "Consent is needed only once, ever, per a specific integration and a user".
I see that docusign uses cookies' values/expiration and can probably reverse engineer a GET call to account-d.docusign to get the bearer from the console app context, but that's not what I'd expect from an API provider.
For reference I'm using the following URL to manually get the bearer from the browser:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=d69848a8-2a93-4d03-ab40-bcabda8a7e8f&redirect_uri=https://www.docusign.com
But as stated above, it does expire in a few mins to get the aforementioned error_description
Thank you in advance!
Response type = code is the Authorization Code grant flow.
But for a console app where the implementation of the application is downloaded to the user's machine, the Implicit grant flow must be used.
This is because the Authorization Code grant flow includes a second API call, from the app to the OAuth Service Provider. This second call is used to exchange the authorization code for an access token. This second call requires a secret value, but there is no guaranteed method for keeping a secret in an app that's downloaded to the user's machine.
The Implicit grant flow immediately returns the access token to your app for use in calling the API.
Using the Implicit grant with a console app
Here are the steps. I also discuss this use case in my Electron React apps post.
The key is to use Private-Use URI Scheme Redirection to handle the authentication and receive the resulting access token. See RFC 8252 ยง7.1
Your app registers a http private scheme such as com.example.name_of_my_app with the operating system (windows). This way, any URL like com.example.name_of_my_app://app will be directed to your application to be processed.
Configure your DocuSign client id (integration key) to enable implicit grant and to use com.example.name_of_my_app://app as a return URL. No secret is needed.
When a user wants to authenticate with DocuSign via your app:
Your app initiates the implicit grant flow with the DocuSign OAuth Service Provider by "opening" the URL
https://account-d.docusign.com/oauth/auth?response_type=token&
scope=signature&client_id=xxxx-xxxx&
redirect_uri=com.example.name_of_my_app://app
Windows should open the default browser to the URL. The result will be the authentication page from DocuSign. Your app should NOT open a web view or similar. The operating system's browser should be automatically activated.
After the authentication is done, consent will be requested if needed.
Next, DocuSign will respond to the browser with a redirect to the redirect_uri. This will trigger your application and give your application the access token needed for API calls to DocuSign.
For some operating systems, your app can close the browser window that was created as a result of its URL open.
See the blog post for more info.
Added
As Ben says, your specific problem is that the authorization code that you receive back in the first step of the Authorization Code grant flow only lasts a minute or so. During that time, you exchange it for an access token (which lasts for 8 hours). But as I say above, you should not be using the authorization code grant flow, you should be using the implicit grant flow.
The token in the response only lasts about 2 minutes. Its true that consent is only needed once, but your problem is not consent.
Let's say we have short-lived access token (15 minutes) and long-term refresh token (7 days).
When should we ask backend to refresh access token?
I see two options:
After user logs in we start a countdown to automatically refresh token one minute before access token expires.
We don't implement timer and we try to refresh access token ONLY if we get 401 response from backend.
In first option I see one advantage -
if access token and refresh token will expired AND user stays on the page, not taking any action, he also doesn't send any http request than the timer still works and user is logged out automatically.
In second option -
if access token and refresh token will expired user will be logged out ONLY if he will make some action on page for example: leave a page or make a http request.
If he will stay on page he won't be logged out automatically.
What is a better implementation on frontend than?
I would recommend option 2 as your default behavior, since it will give you a resilient app. Every OAuth client should do this, since 401s can sometimes also be received for infrastructure reasons in some setups, eg token signing certificate renewal.
Option 1 is an optimization, if you want to reduce 401 responses from APIs. However it can lead to incorrectly developed clients and APIs if you are not careful. Personally I never use it.
Note that an expires_in field is returned with the access token but there is no equivalent field for the refresh token, so the client cannot detect when the user session will expire unless you develop a custom solution.
When coding API calls it is recommended to do this, as in this sample code of mine:
When a 401 is received try a token refresh
On success retry the API call - once only
On failure redirect the user to authenticate again
Out of interest there is an online version of the above app that allows you to test OAuth expiry events to see how this behaves - see my Quick Start page
I need to implement SSO using SAML for my application which is running on NodeJS. I have doubt regarding refreshing the session expiration time for a user who has logged in through SSO.
Upon reading many documents, I came across this flag called IsPassive. My understanding about this flag is that an AuthnRequest will be sent to the IDP SSO url and the IDP will respond at the SP's Assertion Consumer Service URL with the session expiry time (if the session is alive). Is my understanding correct? Apart from that, I have a couple of questions:
I want to develop a backend service to refresh the session timeout and session token for all the SSO users so that the SP's page is not redirected everytime the first session expires. The AuthnRequest does not allow me to send the NameId for the user whose session has to be validated. How can I send the AuthnRequest with the particular user's NameId to check his/her session's validity?
If the first Login response gave me the SessionNotOnOrAfter as time t, will the response to the IsPassive request give me the response SessionNotOnOrAfter as t or t + x, i.e, will the IsPassive response give me an extended time for the session? Also, will the SessionIndex remain the same or will it change?
I am using a serverless backend hosted on AWS Lambda and plan to send repetitive IsPassive requests to the IDP's SSO url from the Lambda.
Since I am a newbie in this, I hope I got all the names and attributes correct to describe my problem
I've scoured the api docs, as well as StackOverflow, and I've yet to find the answer to my question. And it is possible I'm misunderstanding how the system works.
Here's the scenario our client wants:
User logs into our website
At which point we authenticate the user in our system, and One Login via the api.
After the user logs into our dashboard, they can click an link and be redirected to their third party analytics app due to the fact that I've created a new session with One Login.
Here are the steps I've completed.
I've successfully received an access token via --> https://developers.onelogin.com/api-docs/1/oauth20-tokens/generate-tokens
I've successfully used the access token to generate a session login token via --> https://developers.onelogin.com/api-docs/1/users/create-session-login-token
I've successfully used the session login token to create a new session.
I'm receiving the proper cookies from One Login after making the create new session request, and - at that point - if I enter the URL onelogin.com/login, I am taken directly to the dashboard.
At this point I know I'm properly authenticated with One Login. However, I'm not sure how to directly access a third party app from a link on our website.
Thanks.
Two ways:
If the app supports SP-initiated SAML, just navigate the user to the application and it'll do the whole SAML flow- App redirects to OneLogin - OL authenticates user (because you have a session) --- redirects SAML to app
Use the launch endpoint - You can create a URL to an app by using this format: https://app.onelogin.com/launch/{app-id}. For example, you can provide a link to an app like this:
Time Reporting
Details on that endpoint can be found here: https://developers.onelogin.com/api-docs/1/embed-apps/get-apps-to-embed-for-a-user
Take note that you're probably going to want to use the optional flag that makes sure to redirect to your login page, not OL's if you've built a login facade.
We are using Azure B2C to authenticate our users which is working fine. After signup we add some custom claims to our users which were defined in the B2C portal as "User attributes" using the graph api. When I log into the portal I can see these values have been set by our calls, as have some standard claims values(i.e. we also set Display Name by concatenating the givenName and lastName values).
The issue we are having is that after these values are set, they do not appear in the token retrieved by sending the access token to the authenticate endpoints until the user is logged out and back in again (which is obviously a pretty awful user experience after signup). It looks like the original id_token is cached when the user is created and that is what is being returned instead.
This doesnt make sense, as it seems perfectly sensible to let a user update their profile (claims values) while logged into an application and for those changes to take affect immediately without needing to re-authenticate?
Could someone explain how/if it is possible to force the cached id_token on the server to expire so that when we request a id_token using an access token, the id_token contains the most up-to-date claims values?
The issue we are having is that after these values are set, they do not appear in the token retrieved by sending the access token to the authenticate endpoints until the user is logged out and back in again (which is obviously a pretty awful user experience after signup).
Would you mind show the request detail about how you acquire the id_token?
Based on my test, I can acquire the id_token with updated claim successful like steps below:
1 . sign-in a web app
2 . update the DisplayName using Azure AD Graph like below:
POST: https://graph.windows.net/xxxx.onmicrosoft.com/users/{userId}?api-version=1.6
{
"displayName":"newValue"
}
3. re-request the id_token from OAuth2.0 Authorization endpoint using HTTP request without sign-out/sign-in( You also can capture the exact request using Fiddler when you sign-in the app)
GET:https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/authorize?client_id={clientId}&redirect_uri={redirectURL}&response_type=id_token&scope=email+openid&response_mode=query&nonce=HWUavSky1PksCJC5Q0xHsw%3d%3d&nux=1&nca=1&domain_hint={XXXX.onmicrosoft.com}
4 . the update claim value show in the new id_token as expected
To narrow down this issue, you may see whether there is cache for the id_token in your app.
OK so after nearly a month of waiting for a response, the official line is:
"Product Group identify that this is on the roadmap even that we still don't have a final date it should happen in a few months."
So basically they haven't acknowledged it's a bug and they can't tell when this scenario will be supported. Pretty poor level of support to be honest.