Subject: [OAUTH-WG] Authentication

From: Frizz <[email-masked]>
Date: Thu, 4 Sep 2014 11:30:08 +0200

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

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Sep 2014 14:15:07 +0200

Inline
On Sep 4, 2014, at 11:30 AM, Frizz <[email-masked]> wrote:

> The following two scenarios, are they typical use cases for OAuth? Or OpenId-Connect? Or something completely different?
> 
> (5) Client (now with valid Access Token) is redirected to Business Logic Server and completes operation

In 3 the RS returns an error that includes the required scopes.
http://tools.ietf.org/html/rfc6750#section-3
The location of the AS is not included by default.  The UMA spec uses that but OAuth 2 doesn't typically.

The majority of deployed OAuth clients are hard coded to a AS or in the openID Connect case discovery is used to determine the AS.
Typically the client would not start at the resource.

In 4 the AS is challenging the user for username/password via a web form in in the code and implicit flows.
In 5 the users browser is redirected back to the client with a token or code.

In 6 the client access the resource.

> (1) Client directly calls Authentication Server (kinda explicit Login call) with Username/Password and gets an Access Token in return

This is the Resource owner password credentials grant or client credentials flow. 
http://tools.ietf.org/html/rfc6749#section-4.3

Regards
John B.
> cheers,
> Frizz
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 4 Sep 2014 12:15:11 +0000

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.

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

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 04 Sep 2014 16:43:04 +0100

Hi Justin

> 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 t…

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 4 Sep 2014 16:36:50 +0000

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 <[email-masked]> wrote:

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