Uredi

Security tokens

  • Članak

A centralized identity provider is especially useful for apps that have worldwide users who don't necessarily sign in from the enterprise's network. The Microsoft identity platform authenticates users and provides security tokens, such as access tokens, refresh tokens, and ID tokens. Security tokens allow a client application to access protected resources on a resource server.

Access token: An access token is a security token issued by an authorization server as part of an OAuth 2.0 flow. It contains information about the user and the resource for which the token is intended. The information can be used to access web APIs and other protected resources. Access tokens are validated by resources to grant access to a client app. To learn more about how the Microsoft identity platform issues access tokens, see Access tokens.

Refresh token: Because access tokens are valid for only a short period of time, authorization servers will sometimes issue a refresh token at the same time the access token is issued. The client application can then exchange this refresh token for a new access token when needed. To learn more about how the Microsoft identity platform uses refresh tokens to revoke permissions, see Refresh tokens.

ID token: ID tokens are sent to the client application as part of an OpenID Connect flow. They can be sent alongside or instead of an access token. ID tokens are used by the client to authenticate the user. To learn more about how the Microsoft identity platform issues ID tokens, see ID tokens.

Many enterprise applications use SAML to authenticate users. For information on SAML assertions, see Azure Active Directory SAML token reference.

Validate security tokens

It's up to the app for which the token was generated, the web app that signed in the user, or the web API being called to validate the token. The token is signed by the authorization server with a private key. The authorization server publishes the corresponding public key. To validate a token, the app verifies the signature by using the authorization server public key to validate that the signature was created using the private key.

Tokens are valid for only a limited amount of time, so the authorization server frequently provides a pair of tokens;

  • An access token, which accesses the application or protected resource.
  • A refresh token, which is used to refresh the access token when the access token is close to expiring.

Access tokens are passed to a web API as the bearer token in the Authorization header. An app can provide a refresh token to the authorization server. If the user access to the app wasn't revoked, it will get back a new access token and a new refresh token. This is how the scenario of someone leaving the enterprise is handled. When the authorization server receives the refresh token, it won't issue another valid access token if the user is no longer authorized.

JSON Web Tokens and claims

The Microsoft identity platform implements security tokens as JSON Web Tokens (JWTs) that contain claims. Since JWTs are used as security tokens, this form of authentication is sometimes called JWT authentication.

A claim provides assertions about one entity, such as a client application or resource owner, to another entity, such as a resource server. A claim might also be referred to as a JWT claim or a JSON Web Token claim.

Claims are name or value pairs that relay facts about the token subject. For example, a claim might contain facts about the security principal that was authenticated by the authorization server. The claims present in a specific token depend on many things, such as the type of token, the type of credential used to authenticate the subject, and the application configuration.

Applications can use claims for various tasks, such as to:

  • Validate the token.
  • Identify the token subject's tenant.
  • Display user information.
  • Determine the subject's authorization.

A claim consists of key-value pairs that provide information such as the:

  • Security Token Server that generated the token.
  • Date when the token was generated.
  • Subject (like the user, but not daemons).
  • Audience, which is the app for which the token was generated.
  • App (the client) that asked for the token. For web apps, this app might be the same as the audience.

To learn more about how the Microsoft identity platform implements tokens and claim information, see Access tokens and ID tokens.

How each flow emits tokens and codes

Depending on how your client is built, it can use one (or several) of the authentication flows supported by the Microsoft identity platform. These flows can produce various tokens (ID tokens, refresh tokens, access tokens) and authorization codes. They require different tokens to make them work. This table provides an overview.

Flow Requires ID token Access token Refresh token Authorization code
Authorization code flow x x x x
Implicit flow x x
Hybrid OIDC flow x x
Refresh token redemption Refresh token x x x
On-behalf-of flow Access token x x x
Client credentials x (App only)

Tokens issued via the implicit mode have a length limitation because they're passed back to the browser via the URL, where response_mode is query or fragment. Some browsers have a limit on the size of the URL that can be put in the browser bar and fail when it's too long. As a result, these tokens don't have groups or wids claims.

Next steps

For more information about authentication and authorization in the Microsoft identity platform, see the following articles: