I think you’re confusing the authorization grant with the authorization code, which is one mechanism used as part of an authorization grant. The authorization grant is really a concept — it’s “what you do to get a token”, and so the ticket qualifies. The text in the OAuth2 spec is confusing to say the least, it’s something that the community wrestled with for ages and I’m personally not that much of a fan of the results.
I’m not sure where you’re getting that the user doesn’t need to log in to use the authorization endpoint, as the text very explicitly states:
The authorization server
MUST first verify the identity of the resource owner.
So translating this to UMA, that means that the RqP MUST be identified to use that endpoint. This is fine in the narrow ecosystem deployments where all the users have an account at the AS (which is what I understand to be ForgeRock and Gluu’s current deployments), but it’s problematic in wide deployments where Bob’s never heard of Alice’s AS and vice versa.
But mostly it’s problematic if you’ve got an existing OAuth server, which is almost certainly going to require an authenticated session to use the authorization endpoint. This is the reason we couldn’t really deploy UMA with AAT’s as intended in our use case, because the RqP doesn’t have an account capable of generating plain OAuth tokens. And honestly we don’t *want* external people to be able to come in and generate arbitrary plain OAuth tokens, so that would require us to have all kinds of special hooks and checks to make sure that they’re generating only the “right” kind of token. All said, it’s ridiculously complicated and not something I’d want to implement.
And if the RqP can make a plain OAuth token — well then again I say, don’t use UMA, use OAuth. You’re arguing to remove permission tickets and have the requesting party start at the authorization server and use the authorization endpoint. What does UMA buy you in that case? Nothing that I can see — you’re not really doing UMA at all anymore. What you’re describing is OAuth, but with Alice being able to set a policy at the AS that identifies and allows Bob to access stuff. In other words, Alice can turn Bob into an OAuth resource owner. That’s great, I can build that into my OAuth server and call it a day! But it’s not UMA anymore, and I think it’s confusing to style it as such.
— Justin
I'm not sure I agree about the authorize endpoint. The appropriate bits from the OAuth2 spec are:
1.3. Authorization Grant
An authorization grant is a credential representing the resource
owner's authorization (to access its protected resources) used by the
client to obtain an access token. This specification defines [...]
an extensibility mechanism for defining additional types.
and
3.1. Authorization Endpoint
The authorization endpoint is used to interact with the resource
owner and obtain an authorization grant. The authorization server
MUST first verify the identity of the resource owner. The way in
which the authorization server authenticates the resource owner
(e.g., username and password login, session cookies) is beyond the
scope of this specification.
There is nothing here that specifies that the resource owner has to be able to login to the authorization endpoint, where as it is clear that the permission ticket does not qualify as an Authorization Grant.
I think it would be perfectly reasonable to use the authorization endpoint first, order to obtain a code grant that can then be exchanged for the token. The AS would have the opportunity to redirect to the claims gathering endpoint.
If you really don't think it fits with the authorization endpoint, I would prefer we consider adding a different endpoint - the permission ticket just isn't an authorization grant - I don't see how we can get around that.
Cheers
James