Perhaps the resource authorization server uses a separate identifier format and value for users than the IdP
I wouldn’t expect this to be a subject claim in a cross-domain (federated) assertion. Subject claims are scoped to issuer in a federation.
This profile is reusing the same claims as the ID Token. In a normal authorization code flow the Resource AS would redirect to the IDP if there wasn’t a session and get back an ID Token that it would use the claims to perform account resolution to a local user and prompt for consent to issue an authorization code. ID-JAG is providing the same claims and identifiers for account resolution. This keeps the same trust relationship for the resource owner, improves interoperability (no claims mapping needed) and enables the Resource AS to include authentication context into token issuance decisions (eg amr, auth_time, etc).
It's an architectural question for organizations about how the IdP issued identifiers should be mapped to the identifiers that the application recognizes.
How is this different than ID Tokens? This profile is allowing the same flexibility as SSO which has both brown and greenfield deployments and supports JIT or provisioned accounts.
It sounds like what you are advocating for can be solved with vanilla JWT Authorization Grant and ID Chaining Spec. You don’t want to use an ID Token to obtain the grant (audience issue, AS isn’t the IdP or Client) and you want to have Resource AS specific claims in the assertion for identifying the resource owner.
Hi Karl, My comments below.
Thank you for your patience with my suggestions and questions, Atul A couple of other points to add - The ID-JAG has the same `iss`+`sub` as the SSO ID Token for the Resource Authorization Server as RP.
I'm not sure the ID-JAG is required to have the same `iss` or the same `sub` as the ID-Token. Perhaps the resource authorization server uses a separate identifier format and value for users than the IdP, and the ID-JAG Authorization Server (which in my proposal is separate from the IdP) does that mapping before it issues the ID-JAG. The resource authorization server can be configured to trust the ID-JAG Authorization Server instead of the IdP for the ID-JAG. - This ensures the same account linking/resolution logic for SSO can be reused for ID-JAG processing reducing surface area and security issues of generic claims mappings needed for something like vanilla JWT Authorization Grant in a federation. For example, the Resource Authorization Server as RP stores the IdP's iss+sub during JIT from SSO then matches the `iss`+`sub in the ID-JAG.
It's an architectural question for organizations about how the IdP issued identifiers should be mapped to the identifiers that the application recognizes. So if we are able to propose a standard that doesn't preclude the possibility that there may be a separate authorization server, then it makes the standard more valuable.
I think there is sufficient evidence that many large organizations choose to have separation between the authenticating party and the authorizing party, so as a standards body, we should permit and encourage both possibilities.
- The Resource Authorization Server can trust multiple IdPs and therefore multiple ID-JAG issuers (assuming the secure account resolution of multiple federation identifiers)
I'm not sure if it matters whether the party that a resource authorization server trusts for an ID-JAG is a combined "ID Token Issuer + Authorization Server", or just an "Authorization Server". Am I missing something?
I think the issue is that the id_token “audience” restrictions require them to be the same. Otherwise the “IdP Authorization Server” (that didn’t issue the id_token) would need to reject the id_token when received because the “audience” wouldn’t match. I’m not crazy about the idea that says a bunch of different services performing different tasks are still all the same “audience”.
George Fletcher Identity Standards Architect Practical Identity LLC
Hi Jeff, I'm not thinking of changing anything in the draft (e.g. using Transaction Tokens, WITs etc.) I'm only suggesting that we should not assume that the IdP that issued the ID-Token is the same as the "IdP Authorization Server" that issues the ID-JAG.
Atul
Not going against anything Aaron said, is your question
@Atul Tulshibagwale
cause you are thinking ahead of:
1/ A transaction Token could be exchanged for a ID-JAG?
2/ A Workload Identity Token could be exchanged for an ID-JAG? Jeff
Jean-François “Jeff” Lombardo |
Amazon Web Services Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada
Commentaires à propos de notre échange?
Exprimez-vous
ici. Thoughts on our interaction? Provide feedback
here.
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless
you can confirm the sender and know the content is safe.
|
AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez
aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.
|
For some background, the reason for this draft and the ID-JAG in the first place is to enable an Authorization Server to issue its own access tokens in response to a cross-domain artifact. This is better than the other two alternatives
which would be:
1. Client sends the IdP-issued ID Token to the Authorization Server in the other domain (violates ID Token "audience" policy processing)
2. Have the IdP issue an access token that the Resource Server in the other domain accepts (no protocol violation, but experience has shown Resource Server implementers do not want this)
Now to your actual question, why not enable the ID-JAG issuer to be separate from the ID Token issuer. This would also violate the ID Token "audience" processing, since the ID Token would be presented to an entity different from the issuer
of the ID Token.
Hi all,
Great to see the "Identity Assertion JWT Authorization Grant" proposal being accepted by OAuth. I'd like to propose that we
should not assume that the issuer of the ID-Token is the same as the issuer of the ID-JAG. There doesn't seem to be any reason provided for this either in the draft or in the short discussion we had today.
It's just something that is assumed in the draft, and I feel that can be generalized without affecting anything in the draft.
To address Aaron's response that "if you want them separate, then you return to the ID-Chaining draft": I feel there's a lot of value in this (ID-JAG) specification, and being able to apply to more use cases broadens the value of this specification.
I'd love to know what could be potential issues if the ID-JAG issuer is not assumed to be the same as the ID-Token issuer.
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to
[email protected]
_______________________________________________ OAuth mailing list -- [email protected]To unsubscribe send an email to [email protected]
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
|
