Re: [OAUTH-WG] Authentication

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 <frizzthecat@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
>