Not yet, but we plan to do it.

> Am 29.10.2013 um 18:50 schrieb Todd W Lainhart <[email protected]>:
> 
> JohnB> I would have the client use the resource owner credentials flow if it 
> has the password. 
> Torsten> We use OIDC in conjunction with resource owner password credential 
> grant for native apps (no 3rd party apps, just our own apps) 
> 
> John/Torsten - 
> 
> Are you returning an id_token in the resource owner creds flow?
> 
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250
> 1-978-899-4705
> 2-276-4705 (T/L)
> [email protected]
> 
> 
> 
> 
> 
> From:        John Bradley <[email protected]> 
> To:        Torsten Lodderstedt <[email protected]>, 
> Cc:        Todd W Lainhart/Lexington/IBM@IBMUS, 
> "[email protected]" <[email protected]> 
> 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 <[email protected]> 
> 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 <[email protected]> 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)
> [email protected]
> 
> 
> specs mailing list
> [email protected]
> http://lists.openid.net/mailman/listinfo/openid-specs 
> _______________________________________________
> specs mailing list
> [email protected]
> http://lists.openid.net/mailman/listinfo/openid-specs 
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs

Reply via email to