As John points out, that could be either resource owner or client credentials flow, depending on the use case.
-- Justin On Sep 4, 2014, at 11:43 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > Hi Justin > > > On 04/09/14 13:15, Richer, Justin P. wrote: >> Neither of these are authentication (they don't tell the client or business >> logic server who the user is or if they're still there), they're >> authorization and they're both well within the scope of OAuth. >> >> The first one is a redirect flow, that actually works (in OAuth) like this: >> >> 1) Clients calls business logic server (in OAuth, the Protected Resource) >> 2) Server detects no access token, sends an error response to the client >> 3) Client needs to send the user in a browser to the Authorization Server >> 4) Authorization server prompts the user (not the client) to authenticate >> and authorize the client >> 5) Authorization server redirects back to the client with either the token >> (if you're doing implicit flow, inside of a browser) or something the client >> can use to get a token (authorization code flow) >> 6) Client gets the token and calls the business logic server with said token >> >> In your second scenario, you're really doing the Resource Owner Password >> flow defined in OAuth. This is generally a bad idea because it exposes the >> client to the user's credentials and limits you to username/password. The >> flow is defined mostly as a way to help bridge legacy applications into the >> OAuth world. > > That was a client credentials, right ? And in the client credentials case a > (legacy) client can effectively authenticate using whatever credentials it has > > Thanks, Sergey > >> >> >> If you actually do want authentication (i.e., the client knowing who the >> user is) on top of this authorized call to the business logic service, then >> you'll need an identity API, which is what OpenID Connect provides in a >> well-defined well-used standard. >> >> -- Justin >> >> >> On Sep 4, 2014, at 5:30 AM, Frizz <frizzthe...@googlemail.com> wrote: >> >>> Hello there, >>> >>> I have a question regarding Authentication: >>> >>> The following two scenarios, are they typical use cases for OAuth? Or >>> OpenId-Connect? Or something completely different? >>> >>> Flow (A) would be like this: >>> (1) Client calls Business Logic Server >>> (2) Server detects there’s no Access Token in HTTP headers >>> (3) Server redirects to *some* Authentication Server >>> (4) Authentication Server challenges Client for Username/Password >>> (5) Client (now with valid Access Token) is redirected to Business Logic >>> Server and completes operation >>> >>> Flow (B) would look like this: >>> (1) Client directly calls Authentication Server (kinda explicit Login call) >>> with Username/Password and gets an Access Token in return >>> (2) Client uses this Access Token for all calls to the Business Logic Server >>> >>> cheers, >>> Frizz >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
