Single Sign-On with the Delegated Access Control Pattern
Join the DZone community and get the full member experience.Join For Free
Suppose a medium-scale enterprise has a limited number of RESTful APIs.
Company employees are allowed to access these APIs via web applications
while they’re behind the company firewall. All user data is stored in a
Microsoft Active Directory, and all the web applications are connected
to a Security Assertion Markup Language (SAML) 2.0 identity provider to
authenticate users. The web applications need to access back-end APIs on
behalf of the logged-in user.
In this case, you need to find a way to exchange the SAML token received in the SAML 2.0 Web SSO protocol for an OAuth access token, which is defined in the SAML grant type for the OAuth 2.0 specification. Once the web application receives the SAML token, as shown in step 3 of the above figure, it has to exchange it with an access token by talking to the OAuth authorization server.
The authorization server must trust the SAML 2.0 identity provider. Once the web application gets the access token, it can use it to access back-end APIs. The SAML grant type for OAuth doesn’t provide a refresh token. The lifetime of the access token issued by the OAuth authorization must match the lifetime of the SAML token used in the authorization grant.
After the user logs in to the web application with a valid SAML token, the web app creates a session for the user from there onward, and it doesn’t worry about the lifetime of the SAML token. This can lead to some issues. Say the SAML token expires, but the user still has a valid browser session in the web application. Because the SAML token has expired, you can expect that the corresponding OAuth access token obtained at the time of user login has expired as well. Now, if the web application tries to access a back-end API, the request will be rejected because the access token is expired. In such a scenario, the web application has to redirect the user back to the SAML 2.0 identity provider, get a new SAML token, and exchange that token for a new access token. If the session at the SAML 2.0 identity provider is still live, then this redirection can be made transparent to the end user.
This is one of the ten API security patterns covered in my book Advanced API Security. You can find more details about this from the book.
Published at DZone with permission of Prabath Siriwardena, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Health Check Response Format for HTTP APIs
Comparing Cloud Hosting vs. Self Hosting
What ChatGPT Needs Is Context
Operator Overloading in Java