Token Expiry after 15 minutes using WSO2 Identity Server - wso2

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.

Related

ERROR: (gcloud.auth.activate-service-account) There was a problem refreshing your current auth tokens:

When I'm trying to activate a service account using the gcloud CLI command.
gcloud auth activate-service-account --key-file key.json
I am getting the below error since yesterday. I was able to create a service account with the same command 2 months ago and the service account was created at that time.
ERROR: (gcloud.auth.activate-service-account) There was a problem refreshing your current auth tokens: ('invalid_grant: Invalid JWT Signature.', {'error': 'invalid_grant', 'error_description': 'Invalid JWT Signature.'})
What is the issue here?
I've come across this answer which might be helpful on your case. 2 common causes were:
Your server’s clock is not in sync with NTP.
Solution: Check the server time. If it's incorrect, fix it.
The refresh token limit has been exceeded.
Solution: Nothing you can do - they can't have more refresh tokens in use.
Applications can request multiple refresh tokens. For example, this is useful in situations where a user wants to install an application on multiple machines. In this case, two refresh tokens are required, one for each installation. When the number of refresh tokens exceeds the limit, older tokens become invalid. If the application attempts to use an invalidated refresh token, an invalid_grant error response is returned.
The limit for each unique pair of OAuth 2.0 client and is 50 refresh tokens (note that this limit is subject to change). If the application continues to request refresh tokens for the same Client/Account pair, once the 26th token is issued, the 1st refresh token that was previously issued will become invalid. The 27th requested refresh token would invalidate the 2nd previously issued token and so on.
Just to add, please verify the validity of the service account key and try to setup the environment variable again.

How to set custom timeout for session in wso2 apim publisher and devportal?

I am using wso2 apim 4.0.0. I would like to customize (set 1 minute) session timeout for management consoles(publisher, devportal, admin). The way I am following is the official [documentation] (https://apim.docs.wso2.com/en/4.0.0/install-and-setup/setup/security/securing-api-m-web-portals/#configuring-session-time-out) which states to add following lines to deployment.toml configuration file
[tomcat.management_console]
session_timeout = "30m"
[tomcat.global]
session_timeout = "30m"
I tried to modify those configs to 1m:
[tomcat.management_console]
session_timeout = "1m"
[tomcat.global]
session_timeout = "1m"
After restarting, only carbon seems to be affected from changes given above. It invalidates session automatically after a minute. But session timeout for Publisher, Devportal, Admin portals remain unchanged.
I expected the configuration would work on Publisher, Devportal, Admin as well so they invalidate the session after one minute.
I think this is no longer applicable for the publisher,admin and deportals as APIM use OIDC SSO session management methodology for these portals. Portals use IDP side sessions only and by default, it expires at 15mins[1]. From the APIM UI side, we don't use browser sessions and we only check the access token validity period(default 1 hour), if the token has expired we log the user out and might use the refresh token if persisted and then use that token to get a new access token. During that period if the IDP session has expired only the user is redirected to the login page, otherwise the user login happens and the user is redirected to the portal automatically.
Therefore instead of using the above config, you can
Change the session timeout parameter of the resident keymanager from the management console [1]
Update the access token and refresh token timeouts for the publisher, devportal and admin portal service providers.
[1] - https://is.docs.wso2.com/en/latest/guides/login/session-timeout/

wso2-am 2.1.0 jwt token expiration

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

"Provided Authorization Grant is invalid" when using refresh_token WSO2 IS 5.2.0

I recently updated my environment from WSO2 IS 5.0.0 to WSO2 IS 5.2.0. My environment consists of one machine deployed on EC2 AWS instance. I am using MySQL(not the default H2 database). The machine on which the IS is deployed is Windows Server 2012 R2.
I am using the password grant type in order to get access token for particular user and also store the refresh token so that I am able to issue another access token when needed. I am doing the following request in order to get access token:
POST
https://(IS-URL)/oauth2/token?scope=openif&grant_type=password&username=test#abv.bg#localhost.io&password=Asd123##
Configure the appropriate Authorization Basic header
After that I am using the refresh token in order to issue new access tokens. For example:
POST
https://(IS-URL)/oauth2/token?scope=openid&grant_type=refresh_token&refresh_token=
Configure the appropriate Authorization Basic header
After I execute the latest POST call from Postman several times in 2-5 sec interval, after the first 5-7 calls, I start to receive the following error response:
{
"error": "invalid_grant",
"error_description": "Provided Authorization Grant is invalid"
}
I am expecting to receive the new access token and instead I am receiving the mentioned above error. Then I modifiedthe log4j.properties by updating the following lines:
log4j.logger.org.wso2.carbon.identity=DEBUG
log4j.logger.org.wso2.carbon.identity.application=DEBUG
log4j.logger.org.wso2.carbon.identity.mgt=DEBUG
log4j.logger.org.wso2.carbon.identity.oauth2=DEBUG
log4j.logger.org.wso2.carbon.identity.provisioning=DEBUG
log4j.logger.org.wso2.carbon.identity.user.account.association=DEBUG
log4j.logger.org.wso2.carbon.identity.user.profile.mgt=DEBUG
Then I started the IS and tried again the mentioned above scenario and this is what I received in the log file:
[2016-11-15 21:29:18,873] DEBUG {org.wso2.carbon.identity.oauth2.OAuth2Service} - Access Token request received for Client ID GCFfyPSGkykWG4zQTKoDp8NEvjIa, User ID null, Scope : [openid] and Grant Type : refresh_token
[2016-11-15 21:29:18,873] DEBUG {org.wso2.carbon.identity.oauth2.token.handlers.clientauth.AbstractClientAuthHandler} - Can authenticate with client ID and Secret. Client ID: GCFfyPSGkykWG4zQTKoDp8NEvjIa
[2016-11-15 21:29:18,873] DEBUG {org.wso2.carbon.identity.oauth2.token.handlers.clientauth.AbstractClientAuthHandler} - Grant type : refresh_token Strict client validation set to : null
[2016-11-15 21:29:18,873] DEBUG {org.wso2.carbon.identity.oauth2.util.OAuth2Util} - Client credentials were available in the cache for client id : GCFfyPSGkykWG4zQTKoDp8NEvjIa
[2016-11-15 21:29:18,873] DEBUG {org.wso2.carbon.identity.oauth2.util.OAuth2Util} - Successfully authenticated the client with client id : GCFfyPSGkykWG4zQTKoDp8NEvjIa
[2016-11-15 21:29:18,873] DEBUG {org.wso2.carbon.identity.oauth2.token.handlers.grant.RefreshGrantHandler} - Access Token is not in 'ACTIVE' or 'EXPIRED' state for Client with Client Id : GCFfyPSGkykWG4zQTKoDp8NEvjIa
[2016-11-15 21:29:18,873] DEBUG {org.wso2.carbon.identity.oauth2.token.AccessTokenIssuer} - Invalid Grant provided by the client Id: GCFfyPSGkykWG4zQTKoDp8NEvjIa
[2016-11-15 21:29:18,873] DEBUG {org.wso2.carbon.identity.oauth2.token.AccessTokenIssuer} - OAuth-Error-Code=invalid_grant client-id=GCFfyPSGkykWG4zQTKoDp8NEvjIa grant-type=refresh_token scope=openid
For more information, please take a look at the whole log file:
https://www.dropbox.com/s/ygfc9hrrgxjkzkh/console.log?dl=0
Has someone experienced similar issue and could this be bug in the IS or it is caused by some sort of misconfiguration?
I took a look at Refresh token returns invalid grant type but was not able to find direct answer to the question.
Just want to mention that I tried issuing one request per second and tried this for 5 min interval and was not able to reproduce the issue. It seems it happens when the request frequency is high enough.
Thanks in advance.
As per this code and your logs, the access token is neither in 'ACTIVE' nor 'EXPIRED' state. You can look for that particular token in IDN_OAUTH2_ACCESS_TOKEN table. That will give you a hint about what has gone wrong.
Update:
I analyzed your dataset. The problem is that since you have sent the same token request several times, there are many entries in this tables with TOKEN_STATE=INACTIVE. And also you have 2 entries with the same timestamp (i.e. 2016-11-17 11:40:02) in TIME_CREATED column, which has happened to be the latest among all. So when IS tries to pick the latest token (which ideally should be the ACTIVE one) db server returns 2 tokens. But IS has to pick just one. It can be any of those 2 since the timestamp is the same. So when it picks the INACTIVE one, you should see above error.
Ideally, IS should have handled this properly. But as a solution for you, if you do not keep sending the same request very frequently, you should be able to get rid of the error. Just send a request and wait till the response comes. If it takes a lot of time, that's a different issue to analyze and solve.

WSO2 Identity Server SCIM Authorization issue

Having WSO2 IS 5.0.0.SP1 backed by PostgreSQL there is another application reading user information using the SCIM service (filter=userNameEq...)
All works but after certain time the service returns "User is not authorized.." response with a single ERROR level log line. Since that moment all subsequent calls fail with "404 User is not authorized". Even when I log in using the admin account I have no access rights. This state takes for a few minutes and then all seems working again.
We traced the response message to the SCIM service implementation where the authorization is checked. However we are unable to find the root cause of the issue (suspecting some exception is qietly dropped, cache cleanup cleans more than it should, ...)
Any hint / idea is appreciated.
Carpe diem
Gabriel
This seems to be authorization issue. If after trying 3 fail login attempt user locked 0-minutes(Most user used 05 minutes). This is default settings of fresh WSO2 IS pack. After the configured locked-time user unlocked. Then the user have a login with valid credentials. If you need, you can change the login attempt,locked time.Please check [IS_HOME]/repository/conf/security/identity-mgt.properties file. It's having the all configuration.
Issue is resolved (or - reason is identified in another system). In the AD tree one of the domain controllers is external (cloud) and unable to authenticate the technical (wso2) datastore user. When the AD node hostname is resolved to the cloud node, then ldapsearch is unable to return any groups from a sub-domain of the cloud based domain controller (interesting - it doesn't fail).