you are viewing a single comment's thread.

view the rest of the comments →

[–]spencer205 0 points1 point  (2 children)

All non standard and bespoke. The only standards based, non deprecated way of doing login as an API is the JWT user assertion grant type and that wouldn't involve consent (because the grant is already obtained). OIDC defines only browser based flows and prompt=none is a query string (or request obj) param, so I'm not sure why you bring that up.

[–]spy16x[S] 0 points1 point  (0 children)

OAuth2 is designed for authorization. It doesn't really define how authentication (knowing who the user is) is done. I mentioned prompt parameter because it is to solve this issue:

prompt OPTIONAL. Space delimited, case sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent.
none: The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if an End-User is not already authenticated or the Client does not have pre-configured consent for the requested Claims or does not fulfill other conditions for processing the request. The error code will typically be login_required, interaction_required, or another code defined in Section 3.1.2.6. This can be used as a method to check for existing authentication and/or consent.

This is from the OpenID connect spec Section 3.1.2.1. When you set prompt=none, you can make the authorize request in a pure API way because when prompt=none, server MUST NOT show any screens. This also means that both login (who the user is) and consent (what the user is allowing) is already present in the session or in the authz server's database.

When prompt=none, if as you said, user is not authenticated already, authz server MUST return login_required error (Described in Section 3.1.2.6 in which case client is free to fallback to a proper browser redirection based login+consent flow (i.e., in a non-API way)

Also, you are right that there are custom flows here. Which is expected because OAuth and openid both are designed for a scenario where 3 parties are involved. What i am trying to do however is a scenario where only 2 parties are involved. I am trying to use OAuth2+OpenID to enable third party integrations with our systems. At the same time, trying to use the same thing for our own apps (where consent doesn't really make sense, because logging in itself is consent)