1
votes

We need a user of our application to be able to login from multiple browsers/devices simultaneously with WSO2 IS. Currently we're using OAuth2 implicit grant flow.

  1. User authenticates first time. He gets access token #1.
  2. Same user authenticates in second browser or device (same user, same client application/service provider, same scope=openid). He gets access_token #2.
  3. After some time (about five min.) token #1 becomes invalid and user's redirected to login page.

Is it expected behaviour of WSO IS? As per https://is.docs.wso2.com/en/5.10.0/learn/issuing-new-tokens-per-request/ Identity Server by default should return same token on every request, but it does not.

Is it possible to either return the same access token on every new request for the same user+client+scope or have multiple tokens valid simultaneously?

I've tried to issue several tokens with Authorization code grant. It's worse. After issuing new token previous one is revoked immediately.

EDIT

After more accurate testing it appeared that with both flows next issued access token exprires previous one.

API calls used:

https://idm.local/oauth2/authorize?response_type=token&scope=openid%20profile&redirect_uri=https://site/&client_id=xxx

Example tokens. As you can see expiration time is 10 days.

#1
{
  "sub": "[email protected]",
  "aud": "xxx",
  "nbf": 1610816073,
  "azp": "xxx",
  "scope": "openid profile",
  "iss": "https://idm.passport.local:9443/oauth2/token",
  "groups": [
    "ROLE_DASHBOARD",
    "Internal/everyone"
  ],
  "exp": 1611680073,
  "iat": 1610816073,
  "jti": "46ec375e-cb51-4695-869a-07bb737e8de8",
  "email": "[email protected]"
}
#2
{
  "sub": "[email protected]",
  "aud": "xxx",
  "nbf": 1610816249,
  "azp": "xxx",
  "scope": "openid profile",
  "iss": "https://idm.passport.local:9443/oauth2/token",
  "groups": [
    "ROLE_DASHBOARD",
    "Internal/everyone"
  ],
  "exp": 1611680249,
  "iat": 1610816249,
  "jti": "94eadf4e-8554-414b-9244-26418f78bf77",
  "email": "[email protected]"
}

At this time introspection call about #1 token returns {"active":false}

EDIT 2

Such situation's observed when "Token issuer" is set to JWT on Service Provider settings. If I change the settings to "Default" then IS starts returning same access_token on every request as expected.

3
Did you get the access token using your devices as a scope(scope=device_ipad)? Did you configure any token expiration time?Sarangan
scope=openid in all cases. Token expiration time upped to 864000 sec.Alexey Dolgopolov
Are you trying this on a fresh IS 5.10.0 pack? or do you have customizations?Thanuja
docker 5.10.0 image from DockerHub. Rebuilt with added postgresql jdbc driverAlexey Dolgopolov

3 Answers

1
votes

About #3: check the expire time (exp) of the token (open it in https://jwt.io). If the user is in another timezone or has a different clock setting the expiration time will "seen sooner".

If you want to use the same token, then the user should not request a new one and use the same. If WSO2 returns EXACTLY the same token, it will return a token with the same expiration time and WSO2 would reject it again.

I see 2 solutions:

  1. use a token with longer expiration time (several hours, days);
  2. use an apikey instead of token (it has and option to generate with inifinite validity period).
1
votes

This is the expected behavior for JWT access token. Whenever we request a new access token, old tokens will get revoked. But we can easily achieve your use case by selecting the sso-binding type for the access token.

enter image description here

With this, your access token will be bound to the session and enables you to have multiple valid access tokens simultaneously for different browsers/devices.

Now check the authorization code grant type (Note: test this is in different browsers. If you use the same browser you will always get a new token)

FYI, if you really want to use a single token until it expires then you have to switch to the opaque access token. Refer https://is.docs.wso2.com/en/5.10.0/learn/issuing-new-tokens-per-request/#! to know more about opaque token behavior.

0
votes

Did you configure any timestamp skew in your deployment.toml file. The timestamp skew is used to manage small time gaps in the system clocks of different servers.

[oauth]
timestamp_skew = 100

If that timestamp > your expiration time then your token will be invalidated ASAP.

Could you please share the command you are using to retrieve the token?