Since APIs most often give full read/write access to all things so their security needs our full attention at all times. In OAuth 2 there are short lived access tokens (1 hour default) that are valid for an hour or so. Long lived refresh tokens can stay around for a long time. Refresh tokens are converted into access tokens as needed but usually based on duration. If you need access to a resource for 2 minutes an Access Token is all that is needed. If you need access once each day you can use a Refresh token each time you need access. if you has a long continuous running need for access a Refresh Token can be used to get a new Access Token very 45 minutes for example. Each refresh request allows for the reevaluation of user access.
As a result systems tend to store refresh tokens and convert them to a variety of access tokens based on security need on going. In addition Access Tokens are not stored as rule. They are gotten, used and deleted. Refresh Tokens create new Access Tokens.
To impersonate their creator’s rights possession of either of these tokens is all that is needed . That can be a pretty big risk, and Bearer Tokens can stick around for many days for 200 days as note in this Apigee overview.
Extending Access Token Life Time
Continuous Access Evaluation (CAE) is a new Microsoft Active Directory feature that allows access tokens to be revoked based on critical events and policy evaluation rather than relying the tokens lifetime. An access token’s life time can be extended considerably unless there is a CAE driven need to cut short the life time (up to 28 hours). CAE ties to Conditional Access to get its full effect.
Thankfully Microsoft is helping us support CAE now via the Microsoft Authentication Library (MSAL).
To show how easy it is to use this here are few items from the MSAL CAE how to page:
Add code to handle a response from the resource API rejecting the call due to CAE. With CAE, APIs will return a 401 status and a WWW-Authenticate header when the access token has been revoked or the API detects a change in IP address used. The WWW-Authenticate header contains a Claims Challenge that the application can use to acquire a new access token.
Here is a returned string example: “HTTP 401; Unauthorized WWW-Authenticate=Bearer authorization_uri=”https://login.windows.net/common/oauth2/authorize”, error=”insufficient_claims”, claims=”eyJhY2Nlc3NfdG9rZW4iOnsibmJmIjp7ImVzc2VudGlhbCI6dHJ1ZSwgInZhbHVlIjoiMTYwNDEwNjY1MSJ9fX0=””
To learn more about OAuth 2.0 here is a ton of information from Microsoft on how OAuth 2.0 works. It takes a bit of time to understand it all.