[Openid-specs-ab] Using OIDC for "device authentication"

[Adam Dawes]

We do a flavor of this with Firebase Anonymous Authentication
<https://firebase.google.com/docs/auth/web/anonymous-auth>. It's not
exactly a device ID, because the token still includes a normal sub like a
typical login. However, there isn't any profile data or backing credential
for that "account", so for practical purposes it can only be used on that
device. The benefit of doing this, is it allows the user to be "upgraded"
to a regular account by decorating the anonymous account with profile data
and a login method. This is great for shopping cart scenarios where the
underlying app logic can store data for the user and perform other logic on
the user in a "logged out" state.

On Mon, Oct 2, 2017 at 6:52 PM, George Fletcher via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Rich,
>
> Yes that would work though it requires the user to know the client
> credentials. That might be weird for a consumer to know and for public
> clients that don't have a secret would mean just the client_id. I'll have
> to think about this.
>
> Thanks,
> George
>
>
> On 10/2/17 7:00 PM, rich levinson wrote:
>
>> Hi George,
>>
>> I have not explicitly verified this, however, I would imagine that a user
>> using a client device could, in theory, launch a request using the
>> OIDC Authorization Code flow from that device, where the user could
>> provide the client creds for login, and if the az-svr accepted that for
>> login then the identity and access tokens would have the device
>> id as the subject, I think.
>>
>>   Thanks,
>>   Rich
>>
>>
>> On 10/2/2017 11:46 AM, George Fletcher via Openid-specs-ab wrote:
>>
>>> I'm just curious if anyone else has looked at trying to leverage the
>>> OIDC redirect flow but instead of doing end-user authentication...
>>> authenticating the device. I have a use case where one property needs to
>>> redirect the device to the OP and get back a code to exchange for tokens.
>>> The "subject" of the token is the device identifier not the end-user.
>>>
>>> I realize that OIDC was not really designed for this, but it does have a
>>> lot of the protections needed for redirect based protocols:)
>>>
>>> Thanks,
>>> George
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.op
>>> enid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP
>>> 1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9q
>>> clOUTeEg29NkEkknFyDupoNiiA&m=LgekHGfZDUzU6dr1ZRnSu0aa0liugt0
>>> dIscH-h0G4dA&s=O5ro-n7tpA2ELCf1k_v4zw3i40SUE-OBmxvH_CbBbJk&e=
>>>
>>
>>
>>
>>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>



-- 
Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20171002/6066e08d/attachment.html>