OAuth 2 Federation – RS trust external AS
Session Topic: OAuth 2 Federation
Wednesday 5I
Convener: Patrick Radtke
Notes-taker(s): Patrick Radtke
Tags for the session - technology discussed/ideas considered:
OAuth2, Token Introspection
Problem:
Our enterprise has an OAuth2 Authorization Server (AS) that users use for granting consent and revoking tokens. Each SaaS provider we use also has an AS for the resource servers (RS) hosted with them. The user experience is bad since users need to consent in multiple places, and need to visit multiple sites to view what consents are given. From an enterprise perspective there are additional security concerns. If a user’s account is comprised or if the user is fired how can we can we view and revoke granted tokens across all SaaS providers.
Proposition 1:
One method to solving this is to have the RS at the SaaS provider trust tokens generated by out enterprise AS. The group recommended that the enterprise AS generate a simple JWT that contain the issuer and then the RS could verify the signature on the JWT (since it knows the issuer) and use a token introspection endpoint (define through a pre-arranged data sharing) to gather additional information (scopes, subject, audience, validity, etc)). The enterprise AS would need to know a bunch of meta-data associated with the RS such as scopes and scope definitions. Likewise the RS would need to know meta-data about the enterprise AS, such as a verification key, token introspection end-point, etc. It was recommended to look at OpenID connect for how they have defined much of the same meta-data.
Making the SaaS’s RS rely on the enterprise AS is only half the coin. The second aspect is how the client knows to send the user to the enterprise AS. For custom, or configurable clients we could configure the enterprise AS, client id, redirect_uri, etc for those clients. However, for existing 3rd party applications ,such as Google Drive, things are more complicated. The default Google Drive client does not know the user is accessing the enterprise Google Drive and should login at the enterprise IDP, and be sent to the enterprise AS. Additionally, the default Google Drive client won’t be registered with enterprise AS and it may not be capable of or, by enterprise policy, allowed to do dynamic client registration.
Proposition 2:
Alternate propose solutions were to perform AS to AS communication. The enterprise AS could talks to the SaaS AS and mint tokens on behalf of the user. There is currently no specification on how this protocol or delegation would work and the group decided to concentrate more on what could be done within the existing RFCs.
It was pointed out the most complicated aspect of this is not technical, but will be convincing SaaS providers to support externalized authorization servers in the first place.
