Using WSO2AM 2.1.0 we'd like to use the JWT token to pass api, user and application information to the backend service for authorization. The problem is with the JWT validation as the expiration timestamp is set to the current timestamp
reading other resources did not help much:
https://wso2.org/jira/browse/APIMANAGER-4575
https://wso2.org/jira/browse/APIMANAGER-3493
WSO2 Api Manager - How to change the expiration time of JWT?
Content of the api-manager.xml
<CacheConfigurations>
<EnableGatewayTokenCache>true</EnableGatewayTokenCache>
<EnableGatewayResourceCache>true</EnableGatewayResourceCache>
<JWTClaimCacheExpiry>900</JWTClaimCacheExpiry>
...
<APIKeyValidator>
...
<JWTExpiryTime>900</JWTExpiryTime>
<SecurityContextTTL>900</SecurityContextTTL>
</APIKeyValidator>
(even according to the resources the JWTExpiryTime has no effect when KM or GW cache is enabled)
It looks like the JWTExpiryTime is in effect if the token cache is disabled (to be validated), but we would like to cache the access tokens for performance reasons..
Edit: seems if either (Gateway or KeyManager) token cache is enabled, the JWT expiration is simply set to current timestamp (making JWT token unusable without some agreement on backend services about the token leeway/skew time). The token is cached for cache-lifetime (15mins by default), so the backend must allow expired tokens for 15 minutes. Or am I missing something?
It looks like the JWTExpiryTime is in effect if the token cache is disabled (to be validated)
You are correct here. You can set the JWT expiration Timestamp using JWTExpiryTime in {APIM_HOME}/repository/conf/api-manager.xml only when both Gateway and Key Manager cache are disabled.
But if you want the token cache to be kept enabled while preventing your JWT from expiring at the time of JWT generation, you can set the TokenCacheExpiry property in api-manager.xml under CacheConfigurations section as follows.
<CacheConfigurations>
...
<TokenCacheExpiry>900</TokenCacheExpiry>
...
</CacheConfigurations>
With this property you define the cache expiry time duration for the Gateway or the Key Manager, the default being 900(seconds).
For more information, refer the following documentation.
https://docs.wso2.com/display/AM210/Configuring+Caching
https://docs.wso2.com/display/AM210/Passing+Enduser+Attributes+to+the+Backend+Using+JWT#PassingEnduserAttributestotheBackendUsingJWT-ExpirytimeoftheJWT
Related
I have created a token by using the following API Call
https://wso2identityseverip:port/oauth2/token
I used generated token in my API by postman which is giving an accurate response. But after 15 min of idle state when I use the same token in the API it is giving me an error.
{
"code": "900901",
"message": "Invalid Credentials",
"description": "Access failure for API: /url/1.0.0, version: 1.0.0 status: (900901) - Invalid Credentials. Make sure you have provided the correct security credentials"}
Requirement:
Token should expire after an hour. For this I have also added following configurations in my deployment.toml.
[session.timeout] idle_session_timeout= "60m" remember_me_session_timeout= "14d" extend_remember_me_session_timeout_on_auth=false
But still token is expiring in 15 min.
The token expiry time is an application-wise config, and the default oauth token timeout is set to 3600 s(1h). If you haven't changed this to 15m, see the following.
If you are experiencing an issue of the invalid token after session time out, it would happen if your application has enabled SSO Session Based access token binding. Also, you have configured to revoke access token at session expiry (this is by default enabled in WSO2IS-5.11.0 onwards https://is.docs.wso2.com/en/5.11.0/setup/migrating-what-has-changed/#revoke-access-tokens-on-logoutsession-expiry).
Regarding session time-out configs:
The idle session time-out configs that you added as follows,
[session.timeout]
idle_session_timeout= "60m"
remember_me_session_timeout= "14d"
are only affected to each tenant that is created after adding the configuration. (Note the note in the green color box https://is.docs.wso2.com/en/5.11.0/learn/configuring-session-timeout/?query=idle_session_timeout#configuration)
In order to change the configs of the already created tenant or carbon.super tenant, you have to log into tenant via the management console, navigate to main tab -> Identity Providers -> Resident, and change the configs there.
Since the error code (code: 900901) is coming from the APIM side, these answers would also help you to troubleshoot
Refer:
https://stackoverflow.com/a/45173578/10055162
https://stackoverflow.com/a/55137885/10055162
I have tried this with latest IS 6.0.0.
You can change the following.
Default validity period for application access tokens
Default validity period for user access tokens
To do you can add the following to the deployment toml (change the values as per your wish).
[oauth.token_validation]
app_access_token_validity=1800
user_access_token_validity=1800
In the latest IS, the default expiry is 3600 seconds (1hr). But in your case it seems it isn't the case. Adding the above config will update the config files but it will not update your already created SP configs. The config change will take an effect from the next SP creation onwards. To update already created SPs, you have to do it from the carbon console Service Provider settings.
When you do this, make sure to change the refresh token validity period as well.
I am using django rest frameworks JWT library
http://getblimp.github.io/django-rest-framework-jwt/
There are two settings on JWT token expiration
JWT_EXPIRATION_DELTA which is in seconds
The docs on it:
You can turn off expiration time verification by setting JWT_VERIFY_EXPIRATION to False. Without expiration verification, JWTs will last forever meaning a leaked token could be used by an attacker indefinitely.
This is an instance of Python's datetime.timedelta. This will be added to datetime.utcnow() to set the expiration time.
Default is datetime.timedelta(seconds=300)(5 minutes).
and JWT_REFRESH_EXPIRATION_DELTA
Docs:
mit on token refresh, is a datetime.timedelta instance. This is how much time after the original token that future tokens can be refreshed from.
Default is datetime.timedelta(days=7) (7 days).
Im not sure on the different use cases. I set the jwt token expiration delta to 20 seconds.
Then got a token saved it to local waited 20 seconds closed my browser window and re navigated to the site
expecting to not be logged in because the token would of expired but I was logged in.
So then what is the difference between JWT token expiration delta
and JWT Refresh Expiration Delta?
JWT_EXPIRATION_DELTA is the actual time till your JWT token will work. After the time mention in JWT_EXPIRATION_DELTA, whenever you will use this token to access a secure endpoint(that has JWT Auth enabled), it will return a error with message that Your JWT Token has been expired. So you need to keep refreshing JWT Token before it get expired. According to documentation:
Refresh with tokens can be repeated (token1 -> token2 -> token3), but this chain of token stores the time that the original token (obtained with username/password credentials), as orig_iat. You can only keep refreshing tokens up to JWT_REFRESH_EXPIRATION_DELTA
It means that no matter how many times you refresh your tokens, it will always keep the record of the original time when your 1st token was generated(First Time you logged in your user). So if JWT_REFRESH_EXPIRATION_DELTA is set to 1 day, you can't keep refreshing your JWT token after 1 day from when your original token was generated (means your 1st token generated time).
Don't know what mechanism you are using to check in the frontend if the user is authenticated or not. But if you use to check it on the backend (DRF-JWT provides some ready endpoints to verify and refresh tokens), you will find it will not work.
We have tried to set the RefreshTokenValidityPeriod in the identity.xml as -1 to make the refresh token valid forever. But the refresh token was expired immediately when it was set to -1. We are using wso2 API manager 2.1.0 and deployed with docker.
You can't do that. But, if you're fine with the security risk of having a non-expiring refresh token, you can have a non-expiring access token, instead. Both the advantage and risk are the same in 2.
From WSO2 APIM document here Access Token, there are configurations for default expiration time of access token and refresh token. However, can we set different expiration time of them separately for each applications?
Thank you very much.
You can't configure different expiration time for different application through configuration. But, through the API Store when generating new token, you can provide the expiration time through UI.
Refer this link[1] to see how to set the validity time for an application access token from the API Store UI.
[1] - https://docs.wso2.com/display/AM1100/Working+with+Access+Tokens#WorkingwithAccessTokens-Renewingapplicationaccesstokens
The Twitter OAuth 1.0a flow requires authenticated request token to be exchanged with access token at consumer or client side after user has authenticated.
The problem that I'm facing is that generating access token needs authenticated request token, request token secret and verifier but the response from the oauth/authentication api doesn't have request token secret. So how do I temporarily save request token secret from oauth/request_token api call so that I can use it in oauth/access_token api call.
I found some solutions from my explorations like Running a Cache server (Memcached, Redis) or using django session feature. But they all seem to be overkill for this task.
I hope to find a simpler solution.
I'm sure you long ago figured this out, but just for future goolers: I decided to a go a more low tech route and create an OAuth token class which includes fields for the fetched and access token. Basically I take the fetched token, store it, then recall it when accessing (as it's in a different view) and then save the access token. Once (if) that's successful than I delete the fetched token.
There's likely a more glamorous way to do this, but if you're clever with your naming convention you can easily keep them straight (i.e. add a CharField for provider and just save the fetched token as twitter_fetched, and the access token as just twitter).
This has the added benefit of allowing you to create an OAuth1 or OAuth1Session from the stored access token.