Seeking guidance on the implementation of native/rich client flow

[Todd W Lainhart]

> I would need to know more about the other credentials.  I am assuming a 
desktop app if it is Eclipse based. 

That's right - an Eclipse-based desktop app.  The login dialog raised by 
the app ultimately uses Apache httpclient to negotiate auth with the AS. 
That dialog allows for the entry of username/password, a client-based 
certificate, or smart-card.  On the feature list is SPENGO (Kerberos). 
Also a CLI, similarly using httpclient.

>  If it is going to authenticate based on some other credential already 
in the browser then use the code flow. 

This hadn't occurred to me.  Basically the user needs to know how the AS 
is configured for auth.  If cert-based or Kerberos, they enter their 
certificate and the native client (with auto-redirection turned off) 
initiates the code flow, assuming no challenges, until its redirect_uri 
returns in the Location header.  If the AS is configured for 
username/password, use the password flow.

Ideally I was thinking that the client wouldn't have to switch flows based 
on how the AS is configured, but perhaps that's unrealistic.  (In our 
OAuth extension, we implemented a proprietary sign-in endpoint that 
optionally took username/password, and returned a token).





Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart at us.ibm.com




From:   John Bradley <john.bradley at wingaa.com>
To:     Torsten Lodderstedt <torsten at lodderstedt.net>, 
Cc:     Todd W Lainhart/Lexington/IBM at IBMUS, 
"openid-specs at lists.openid.net" <openid-specs at lists.openid.net>
Date:   10/26/2013 08:10 AM
Subject:        Re: Seeking guidance on the implementation of native/rich 
client flow



I would have the client use the resource owner credentials flow if it has 
the password.   If it is going to authenticate based on some other 
credential already in the browser then use the code flow. 

I would need to know more about the other credentials.  I am assuming a 
desktop app if it is Eclipse based. 

John B. 

Sent from my iPhone

On Oct 26, 2013, at 8:52 AM, Torsten Lodderstedt <torsten at lodderstedt.net> 
wrote:

We use OIDC in conjunction with resource owner password credential grant 
for native apps (no 3rd party apps, just our own apps)



Todd W Lainhart <lainhart at us.ibm.com> schrieb:
I'm referencing http://openid.net/specs/openid-connect-core-1_0.html 

We have an Authorization Server that supports SSO via session extensions 
to OAuth 2.0.  We're looking to replace that protocol w/ OIDC.  There's a 
couple of sticky points that I'm not sure how to translate. 

1) Rich/Native Client login 

Imagine an Eclipse-based rich client accepts user credentials and receives 
a bearer token in return.  The negotiation may be basic, 
credentials-based, SPENGO.  The client is anonymous.  Rather than using 
the Resource Owner Password Credentials Grant (where username/password are 
REQUIRED parameters), we opted for a custom endpoint so that the AS could 
determine if the request was authenticated in the absence of 
username/password.  Similar to Resource Owner Password Credentials Grant. 

I'm wondering what the guidance is for such a setup in OIDC.  Implicit 
requires the native client to follow (presumably) 302s with the AS until 
it gets the final 302 to the callback location.  Seems messy for this 
setup. 

In the absence of guidance/precedent, I'm inclined to think that a 
Resource Owner Password Credentials Grant style extension is the way to go 
for this scenario.




Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart at us.ibm.com


specs mailing list
specs at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
specs at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20131028/a24c7a84/attachment.html>