Why don't the IdP requests the access token from the AS?

[randomstuff]

The scenario described works as follows:

1. client obtains ID token;
2. client exchanges ID token with IdP against JAG;
3. client requests AT from AS using JAG as an assertion;
4. client uses AT on the RS.

A downside of this approach is that in step 3, the client must be registered on the AS.

Why wouldn't/couldn't the AS take care of step 3?

This would make the process simpler for the client:

• the client does not need to know that the RS is associated with another domain;
• the client does not need to know that the AS exists at all;
• the client therefore does not need to have credentials for the AS.

The fact that the RS is in another domain would be transparent for the client. You could have one deployment where the RS in in the same domain and another deployment where is is in another domain without having to change the client logic.

Modified scenario:

1. client obtains ID token;
2. client exchange ID token with IdP against AT; a. in order to obtain the AT, the AS might need to generate an assertion and send it to the AS
3. client uses AT on the RS.

One downside is that from the point of view, the token are issued to the IdP but surely this can be worked-around with some extension.

[kamronbatman]

The approach we took (which is malleable, as we want to build a simple and reusable flow with the least assumptions), is to have the least amount of burden on both the client (requesting application) and the RS AS. In doing that, step 3 is fine because right now clients already are registered with the RS AS to request tokens directly and facilitate SSO flows. We wanted to lean into that by shifting as much of the burden to the identity provider, especially since the identity provider has all of the information about the user/organization and their relationships.

I do like the simplicity of the proposed modified scenario and I think we should continue hammering out details to see if this kind of approach could work.

I think we also agree that front loading the client_id and resource identifiers for mapping on the identity provider is not ideal. Unfortunately, I also believe requiring the IdP to register a client on every RS AS to do a new on-behalf exchange is not ideal either, especially since that is technically 3rd party to the existing client and AS oAuth registration/trust relationship.

[randomstuff]

So I've been thinking (more/better) about my modified scenario. Some drawbacks are:

• If a refresh_token was issued, the IdP now would be responsible for handling the token refresh request and forwarding it to the AS. I guess the IdP would have to store the original refresh token and send a new refresh token to the client.
• The IdP would now be responsible for handling token revocations requests from the client. For the refresh token, the the approach from the previous point could be used but this is more complex for the access token.
• The IdP would have to forward (and possibly filter/translate) many parameters such as scope, etc.
• The client would not have the AS server metadata as it would not have a direct relationship with the AS.
• DPoP forwarding would not work.

[sdesen]

If all AS responsibilities required for a typical OAuth consent flow were shifted to the IdP, then the IdP would become the AS for an intents and purposes, and then the Client would just make a typical request for an access token. No other steps would be needed. This spec is intended to leverage the common scenario where OAuth relationships exist and the AS may be independent of the IdP.

However, I agree it makes sense to think about where changes can be made for the scenario where the relationship might not already exist, so very much appreciate this comment.

For this point:

the client does not need to know that the RS is associated with another domain;

I am not sure I understand if this is true, because the client needs to make the resource request regardless from the RS.