Access token generated here last only for 60 minutes , how can i generate token so that it can be used without any time bound.
There isn't a non-expiring token that I know of whether it's a DEVELOPER_TOKEN, Oauth, or JWT. Tokens all expire and have to be refreshed.
Related
Trying to use Salesforce OCAPI from an app.
On the JWT Auth documentation: https://documentation.b2c.commercecloud.salesforce.com/DOC2/index.jsp?topic=%2Fcom.demandware.dochelp%2FOCAPI%2Fcurrent%2Fusage%2FJWT.html
A JWT has a lifetime of 30 minutes. Before the token expires, you must exchange it for a new token if you want to extend the total lifetime.
If a registered user opens the app after 31 minutes and the persisted JWT is expired, then how is the way to refresh it without prompting login screen again? (persisting user credentials is out of the question due to security vulnerability)
As the documentation states, you cannot refresh it if it has expired. You must prompt for the login screen again.
I suggest having your app refresh the token automatically in the background.
You can save exp (the token expiration-time) from payload section in your db, try to check before intiatling new call if its expire then you can use the /customers/auth resource to get new token. You must include the current token in the Authentication:Bearer request header, and specify the customer type as "type":"refresh".
History
Sessions-Cookies Age: As I know JWT use for decrease DB requests. sessions are normally stores in DB and all request need query to authentication the request. In small website and web app it's not a problem but in big apps performance is very important.
JWT Rise: With JWT you can skip this step (query to DB for authentication) and can use valid JWT that's signing with your server. You should send JWT token in all request in header but if this token is stolen the thief can use it to authenticate forever.
To protect this you can add expire time in your JWT but before expire time the thief can use this as user can. Now you can decrease expire time (for example 10 mins) to protect users but after expiring the token real users should login with user and password and this is a nightmare.
The Refresh Token is born: Now we can mixed JWT with cookie concept. refresh tokens are store in DB and you can control this by login and logout. after access token (a JWT token with short age) expired clients sends request to some end point to refresh access token in this end point sever check the DB and search for refresh token. if refresh token in White list (or not in black list) the sever generate new access token and return to clients. Now you can store access token in memory and refresh token in local storage or somethings like this.
XSS attack: local storage is not safe and with XSS attacks hackers can steal your local storage.
httpOnly cookies: You can store JWT tokens in httpOnly cookies. httpOnly cookies set from server and clients can't access this from JS.
CSRF attack: New problem with httpOnly cookies is CSRF attack. CSRF attacks come from sessions-cookie age.
My approach
Refresh tokens is very similar to cookies and now we are using cookie and JWT together access token is traditional JWT token and Refresh token is traditional session's token. every 10 mins (JWT age in my example) we are login with refresh token (or session's token) and between them we use access tokens.
If users send 100 request every 10 mins my DB request for authentication decrease 100x
NOW My Question
Did I understand how to use the JWT?
Nice explanation, I think you understand it well.
To add to your explanation, you may want to rotate the refresh tokens: after a refresh token is used to obtain a new access token, return a new refresh token and invalidate the old one. This would prevent someone who gained access to the old refresh token from using it.
Keycloak refresh token expiry is tied to SSO timeouts. If SSO Session Idle is set to 30 minutes, the refresh token will only work for 30 minutes. Session Idle can only be as large as Session Max, therefore the lowest of both is taken as the max refresh token life. How to specify the Refresh token expiry separately as we have for the access token? If the refresh token expires do we need to get another refresh token. Ideal refresh token expiry time?
A client application uses the refresh token to get a new access token without user interaction. It should do so before, or shortly after the access token expires. It will then receive a refresh token which is again valid for 30 minutes (Keycloak Session Idle Timeout). The client can repeat until the Session Max timespan is over.
As a client don't let the refresh token expire:
If the refresh token has expired, the client needs to direct the browser to the authorization endpoint. To prevent this, your application should use the refresh token when the access token gets invalid. Even better: Schedule a refresh for the time before the access token expires.
Scope offline access
As an alternative, the client could request scope "offline access". In this case, the refresh token lifetime is not bound to the SSO Session idle and Max settings.
For details see https://www.keycloak.org/docs/latest/server_admin/index.html#_offline-access
I need the IdentityServer3 session to expire at the same time as the access token. When the access token expires the user is being redirected to IdSvr it's just automatically issuing new Id and Access tokens. I want to force the user to authenticate again when the access token expires. I'm using the Implicit flow so I don't believe refresh token lifetimes come into play. I'm also using the OIDC-client-JS library.
Your approach doesn't make sense -- what would happen if there were 2 different access tokens?
The better approach is from the client to pass the prompt=login or max_age parameter on the authorization request. See the docs for more info: https://identityserver.github.io/Documentation/docsv2/endpoints/authorization.html
If you exchange a short-term access token to extend it to 60 days using
https://graph.facebook.com/oauth/access_token?client_id=(APP_ID)&client_secret=(APP_SECRET)&grant_type=fb_exchange_token&fb_exchange_token=(AccessToken1ST)
When the access token returned from this (AccessToken2) is about to expire, can you use the original short-term access token (AccessToken1ST) to exchange for a new access token (AccessToken3)?
I would test it out, but it's just returning the same access token over and over, since access token 2 has not expired yet.
I know I could probably do this with access token 2, but I'm reading access token 1 from a certain file, since I am not logging in with a user, I just want to read public facebook data and would rather not have to manually update access token 1 ( since I don't have write access to it) and would rather just use access token 1 to generate access token 3 if it is possible.
You cannot exchange an expired token - but only a short-term access token BEFORE it expires.
Your languages indicates that you can exchange expired tokens, which defeats the whole purpose of expiring them!