Lifetime: 5 minutes
Format: opaque (configurable to be JWT per client)
Access tokens are short-living tokens, which are used to access the UserInfo endpoint to get the claims of the authenticated user.
However, access tokens can also be used to access resource servers where the trust between client and resource server is only established via the edu-ID. Opaque tokens can be verified using the token introspection as documented further below. Alternatively, the client requesting the access token can be configured in the Resource Registry to obtain the access token as JWT such that it can be verified by the resource server before processing the request from the client. However, note that (other than Introspection), manual verification of a token does not check whether a token has been revoked yet.
If the access token is meant for use at a separate resource server, the audience claim in the access token needs to be set accordingly by the OP. Please contact us if you have a use case for this since by now, self-service support for resource servers is not yet implemented.
Lifetime: 4 hours
Format: JWT
User-related claims: sub (subject type and more claims configurable via Resource Registry)
By default, any ID Token contains the sub claim as well as some descriptive information about the authentication. The sub claim by default is a pairwise identifier which is a base32 salted hash of the username and the sector_identifier_uri given in the client description in the Resource Registry. The sub claim can also be configured to be a public identifier which then has the value of the swissEduPersonUniqueID.
In the acr claim you can see whether the user is authenticated only by password of with a second factor. Please refere to the 2-step login documentation for more details.
In the Resource Registry you can configure in the attribute settings of your client which additional user-related claims should also be included in the ID token. Adding more data about the user in the ID token is however not recommended. Please refer to our best practices page for details on when claims should be included in the ID token.
Find below an example ID Token:
{
"at_hash": "qveVeMmfX3Gyd6l5YwqHZg",
"sub": "MA2ZRIYFC67J6MEXNA4LMSNQB7ZFMN5Y",
"aud": "apache_mod_openidc_testing",
"acr": "password",
"auth_time": 1646151333,
"iss": "https:\/\/login.test.eduid.ch\/",
"exp": 1646165737,
"iat": 1646151337,
"nonce": "Epg0I0IH3xeuZ2Em1JjzVmLZKX_M452HX0bBAIUAzeo",
}Supported: If the refresh_token grant type is activated for the client in the Resource Registry
Lifetime: 30 days (configurable in the Resource Registry)
Chain Lifetime: 30 days (configurable in the Resource Registry)
Format: opaque
Refresh tokens are used such that a user can have a longer session on a client application, and such that access tokens and ID tokens can be renewed without the need of a re-authentication of the user. This can for instance be useful in mobile applications such that the user does not need to re-authenticate each day.
The use of a refresh token is made transparent to the user. After authentication the consent screen shows a message indicating that the service is allowed to retrieve identity data without further login for a certain time span. A user may reject the consent and thus abort the login flow.
Clients that make use of refresh tokens should provide an option to revoke the refresh token. See the Token Revocation section below for details.
In the Resource Registry client operators can configure the token lifetime. If a refresh token is used to fetch new tokens, also a new refresh token is issued. From this moment on, the old refresh token is invalidated and another usage of it invalidates the whole chain of tokens.
Another configuration option allows for specifying the total lifetime of a chain of refresh tokens. That means, if refresh tokens are renewed, the whole chain cannot be valid for longer than a certain chain lifetime.
The edu-ID IdP supports token revocation according to RFC 7009. The revocation endpoint can be found on the discovery endpoint https://login.eduid.ch/.well-known/openid-configuration.
Client applications that request and make use of refresh tokens are asked to offer token revocation for their users.
The edu-ID IdP supports token introspection which can be used to verify that a given token is valid, according to RFC 7662. The introspection endpoint can be found on the discovery endpoint https://login.eduid.ch/.well-known/openid-configuration.
Note that the token introspection by specification requires client authentication. If you want to use token introspection from a resource server which is not a registered client in the Resource Registry, please contact us.