Is it possible to configure jwt token expiration time (exp property) for an Okta OpenId Connect application?
It seems to be set to 1 hour from issuing time (iat property) for both implicit and authorization code grants.
the expiration time of our OIDC tokens is not configurable and is indeed fixed to 1 hour. It's up to your app to use the refresh token and ask for a new access token (in the authorization code flow scenario) or simply call the authorize endpoint again to get a newer token (in the case of the implicit flow).
Related
I'm working on a project (nothing production-level, only for leveling up my skills) and I'm using JWT to handle authentication.
From what I've read, using a JWT only as an access token is quite unsafe, and hence we need refresh tokens. So, on login, the server returns an access token and a refresh token (which I will be storing in an httpOnly cookie). The access token expires in a short time, but the refresh token is used to get a new one when it does.
My question is, when do we use the refresh token to get a new access token? Is it when the user wants to get a protected resource and finds that the access token is expired (and the refresh token has not) or do we send a new access token each time the user wants to get the protected resource? I'm confused about when and where the refresh token comes into play.
(I'm using React for the frontend and Nodejs for the server)
You're using some security token so it mean that your system has some protected resources. Those resources can only be accessible on successful validation of the token. As you're using the JWT Token (usually for stateless authentication) and your system is granting both access_token and refresh_token to the client, so on server side you can use some authentication interceptor to validate the access_token in the each private request and return some error code on token expiration. On the client side you could also use some filter which should capture the error code and by utilizing the available refresh_token it should request for new access_token from the server. In case of refresh_token expiration your system should follow the route of fresh authentication.
The refresh token can be used at any time to request a new access token. Checking the validity of the access token before he request is one way of accomplishing that. Another common practice is to refresh the access token if it is within a certain timeframe of the current token expiring. A simple cronjob can work in this case. If you assume the access token is not used in multiple places (which it shouldn't be) then the current access token can be invalidated when the new access token is created. Also, for maximum security, the refresh token should be replaced with the access token. This limits security risk around a long-living refresh token becoming compromised.
In our webapplication the users are signed in using Amplify/Cognito's Auth.federatedSignIn() based on a SAML identity provider.
The related OAuth flow is configured as Authorization code grant.
Is it possible to check whether a user has a "valid" session WITHOUT refreshing the identity- and accesstoken?
With valid session I mean that identity- and access-token did not already expire.
I have tested these two methods - both are refreshing the tokens (as long as the refresh token is valid):
Auth.currentSession()
Auth.currentAuthenticatedUser()
Thanks for your support!
I have 2 website that are using identity server Authentication (which is a third website)
if i log out from the identity server website (i am using quick start) how can i force the 2 other website to validate if the user is still log in, and this on every round trip to the server (post back).
For browser based apps you can call the session endpoint:
All applications that the user has logged into via the browser during
the user’s session can participate in the sign-out.
This will however not invalidate JWT tokens as these are self-contained and remain valid until expiration.
The only way to logout a JWT 'almost realtime', is to set the expiration to a minimum and use refresh tokens to renew the access token.
These refresh tokens can be revoked using the revocation endpoint:
This endpoint allows revoking access tokens (reference tokens only)
and refresh token.
This way you don't need a roundtrip on each call. An alternative that does is to use reference tokens:
When using reference tokens - IdentityServer will store the contents
of the token in a data store and will only issue a unique identifier
for this token back to the client. The API receiving this reference
must then open a back-channel communication to IdentityServer to
validate the token.
Using the revocation endpoint you can revoke the reference tokens at any time you like.
Trying to implement OpenId Connect in Web Application consisting of following components
Identity Provider
Resource server
Single Page Application acting as Client.
Identity Provider and Resource Server are the same application.
SPA use Password Flow to get access_token and stores into the cookie. Storing access_token into cookie has it's security threads, but's it's a different story.
Problem
access_token issued by IdP is expired after 30 min and SPA needs to renew token without asking users for credentials again.
Solution
IdP returns refresh_token along with access_token. Whenever SPA gets 401 from Resource Server, it sends refresh_token to IdP and get's new access_token back.
Problem
Sending refresh_token to SPA is bad practice.
A Single Page Application (normally implementing Implicit Grant) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Suggested solution
When the Access Token has expired, silent authentication can be used to retrieve a new one without user interaction, assuming the user's SSO session has not expired.
I think Silent Authentication is not applicable to Password Flow when IdP and Resource Server is same application. access_token issued by IdP is only piece of information which can be used to authorize against Resource Server/IdP after its expiration, how a client can convince IdP to issue new access_token? (without sending refresh_token)
Found angular-oauth2-oidc library which uses refresh_token to renew access_token.
What is best practice/solution in this case to renew access_token?
technical details
Identity Provider - ASP.NET Core + Openiddict library.
SPA - AngularJs application.
Single page applications must not receive refresh tokens. That has been established rules in OAuth 2.0 and OpenID Connect.
One good option I see here is to use Implicit Flow. This will establish a front channel session from your browser to Identity Provider. With password grant type you do a back-channel call (POST), so you don't get such session.
Usually this is a cookie which points to information about previous logged in status (these are identity provider specifics). With completion of the flow, SPA will receive the access token. As you figured out, it will expire. But once that happens, SPA can trigger another implicit flow, but this time with prompt query parameter.
prompt
Space delimited, case sensitive list of ASCII string values that
specifies whether the Authorization Server prompts the End-User for
reauthentication and consent. The defined values are: none , login, consent and select_account
If you identity provider maintain a long lived session (ex:- few hours or days) or if it maintain a remember me cookie, SPA could use prompt=none making it to skip login step from identity provider. Basically, you are getting browser based SSO behaviour with this.
Using the Resource Owner Password Credentials flow defeats the refresh token storage argument: instead of not being able to store the refresh token in a secure place, the SPA would now have to store the Resource Owner credentials in a secure place (assuming you want to avoid requesting username/password from the user frequently). The Implicit grant was designed for usage with an SPA, so it is better to stick with that.
Further to previous answers, the latest OAuth working group guidance for SPAs no longer recommends use of the implicit flow.
If you have simple, shared domain app (IdP, RS and client on a single domain) then you should consider not using OAuth at all. From the doc:
OAuth and OpenID Connect provide very little benefit in this
deployment scenario, so it is recommended to reconsider whether you
need OAuth or OpenID Connect at all in this case. Session
authentication has the benefit of having fewer moving parts and fewer
attack vectors. OAuth and OpenID Connect were created primarily for
third-party or federated access to APIs, so may not be the best
solution in a same-domain scenario.
If you are using OIDC/OAuth in a SPA, they recommend the auth code flow with PKCE.
Trying to implement a secure authentication method with JWT for an API which will be consumed for many clients including web (Single Page App), desktop, mobile I've came up with this system:
Client calls /auth/login with username and password set
After verifying server returns two tokens an auth_token and a refresh_token
Auth token is short lived 15 minutes and is used on every following API call
Refresh token is long lived maybe a 12 hrs to a week BUT is signed with a secret key in the format user_pass + long_string
After the token expires a called to /auth/renew is called
The auth token is sent to check how long it's expired (no longer than an hour)
The refresh token is sent as well and is validated using the user's password
If refresh token isn't expired and the auth token isn't expired for a long time, a new auth token is sent back
If the user's password has changed, the refresh token is invalid and the user is required to re-authenticate after their existing short lived auth token has expired
While there is a small window for the auth token to be expired and still be valid, and there is calls to the database made; is this an overall secure way to authenticate using JWT and to handle password changes and token refresh?
Don't try to implement your own authentication infrastructure. Chances you'll get a secure implementation are minimal and now you'll have to maintain all that code also.
Better use a authorization server from a reputable origin, like Thinktecture IdentityServer or Azure Active Directory and use standard libraries and protocols.
Some problems I see with your proposal:
if you do not sign the access token, what prevents me from changing
the claims inside?
if you need the user's password to validate the refresh token, you must store it in a way that you can retrieve it in clear text. Passwords should only be stored as a salted hash preventing you from getting to the clear text.