[Openid-specs-ab] Other grant types and scope openid

John Bradley ve7jtb at ve7jtb.com
Mon Jul 30 13:26:57 UTC 2012


You know the browser is present and have whatever state exists between the IdP and user at that point.

So it might be better to say that you know the user's state with the IdP.

In the client credentials flow there is no state for the user at the IdP.
So I agree this needs some more thought.

John 
On 2012-07-30, at 4:32 AM, Torsten Lodderstedt wrote:

> How do you know a user is present in mode prompt=none?
> 
> Am 30.07.2012 12:07, schrieb Nat Sakimura:
>> OpenID Connect is protocol independent.
>> OpenID Connect Standard is an OAuth code and implicit flow binding.
>> You could equally define other bindings, and if the authentication
>> scheme in the binding
>> involves user authentication, then ID Token should be issued.
>> 
>> Having said that, neither code nor implicit flows are confined to browser.
>> An app could use either of them.
>> 
>> Important thing is that for ID Token, there has to be some kind of
>> user-in-presence
>> authentication going on. ID Token is a token about this authentication event.
>> 
>> On Mon, Jul 30, 2012 at 2:14 AM, Torsten Lodderstedt
>> <torsten at lodderstedt.net> wrote:
>>> Hi Nat,
>>> 
>>> what is the difference between browser session and authentication session
>>> given that ID token are only issued by browser flows?
>>> 
>>> Or are you saying an id token should also be issued for other grant types
>>> (my original question)?
>>> 
>>> regards,
>>> Torsten.
>>> 
>>> Am 30.07.2012 08:55, schrieb Nat Sakimura:
>>> 
>>>> ID Token is not tied to the browser session, but it is tided to the
>>>> authentication session wherever it happened.
>>>> It could be app that is in the session, and it could be a browser.
>>>> The important thing is that it is tied to the user being present in
>>>> the session.
>>>> 
>>>> If you do not use ID Token, it is not an authentication session anymore.
>>>> ID Token always returns the information about the user who
>>>> authenticated (and authorized resource access.)
>>>> The result of resource access (e.g., profile data) does not have to be
>>>> that of the person who authorized.
>>>> For example, the university controller may allow access to the
>>>> graduation record of the subject to the company
>>>> the subject has applied to. While the profile data returns that of the
>>>> subject, the ID Token returns the
>>>> information about the controller.
>>>> 
>>>> So, as long as you want to do Authentication, you should always use ID
>>>> Token.
>>>> Otherwise, you need to create a proprietary API that essentially act
>>>> the same as ID Token.
>>>> OAuth 2.0 as is does not provide that facility.
>>>> 
>>>> Nat
>>>> 
>>>> On Mon, Jul 30, 2012 at 3:17 PM, Torsten Lodderstedt
>>>> <torsten at lodderstedt.net> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> what is the expected behavior in case a client requests the scope
>>>>> "openid"
>>>>> with a grant type other than code or token? For example, an app could
>>>>> request it at the token endpoint using "Resource Owner Password
>>>>> Credentials". Given the recent discussion on refresh tokens and id
>>>>> tokens,
>>>>> the id token concept seems to be tight to browser sessions. So I don't
>>>>> see a
>>>>> need to return an id token to apps in cases where no browser session is
>>>>> involved.
>>>>> 
>>>>> Comments?
>>>>> 
>>>>> regards,
>>>>> Torsten.
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 
>>> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab



More information about the Openid-specs-ab mailing list