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
