search

aaronpk / oauth-first-party-apps

https://datatracker.ietf.org/doc/html/draft-parecki-oauth-first-party-apps
Other
10 stars 8 forks source link

why not define a new grant type for this flow (not for the different authentication factors) #109

Open Sakurann opened 1 month ago

Sakurann commented 1 month ago

it honestly feels like a huge stretch to use authorization grant type for what is defined in this specification, given that:

  1. client is authenticating the user/passing the info used to authenticate the user

  2. a new endpoint

    agree that there is probably no need for the new grant types per different authentication factors, but if you are defining a new parameter authorization_code, it is probably more honest and cleaner to define a new grant type to get an access token based on this new artifact from an authorization challenge endpoint. Security properties for the authorization code from a usual authorization endpoint and this new authorization challenge endpoint is also probably different, no? (I think I am slightly contradicting a comment in another issue #102, but a new grant type really feels better.)

gffletch commented 3 weeks ago

I think the rationale (for me anyway) is that the goal is any existing OAuth authorization request can be made via the new endpoint (just like we didn't create a new grant_type for PAR). I'm not sure what the AS would do different for the request over a standard auth code flow? The goal is to return a code the client can use to request tokens as it normally does. This also keeps the models similar if the AS requires the user to go through a web flow.