[Openid-specs-ab] OpenID Connect and Identity Delegation

Matias Woloski matiasw at gmail.com
Fri Mar 29 00:12:33 UTC 2013


I took the opportunity to write down what I understood, taking ideas from
Mike and Nat and adding the scenarios for context. Forgive my informality
:)

The authorized presenter (azp) is a party that can legally present the
token to an audience. An audience (aud) is a party that the token can be
legally presented to.  In other words, "azp" constraints where the token
could come "from" and "aud" constraints where the token can be sent "to".
[according to Mike, "azp" does not constraints though]

Typically, this is useful in a scenario where an application running on a
device needs to call a backend service and authenticate not only the user
of the device but also the application calling it. In this scenario, the
authorization server generates a token like:  { "aud":
"backend-service-clientid", "azp": "device-client-id", "sub": "user" }. If
the backend service does not check the "azp", any other app on the device
could have obtained a token for that backend and successfully call this
backend service.

Another scenario where this is useful is when delegating the identity of
the user who has logged in to a web application which then calls a web
service on behalf of the user. In this case, the original "user" id_token
could be exchanged by an authorization server for a new id_token targeted
to the web service ("aud" = "web-service-clientid") and whose authorized
party is only the web application ("azp" = "web-app-clientid"). In that
way, the web service could check that the token is coming from a web
application it trusts.

Matias

On Thu, Mar 28, 2013 at 9:05 PM, Nat Sakimura <sakimura at gmail.com> wrote:

> Could you point me to the text in OAuth spec describing it?
>
> Also, there are legitimate cases where changing hands happens, which is
> not leaking.
> As long as the original party that has gotten the bearer token is
> consciously handing it to another client, it should be fine. e.g.,
> sometimes connected client handing it to the server component that has a
> different client_id.
>
> Nat
>
> 2013/3/29 Mike Jones <Michael.Jones at microsoft.com>
>
>>  Changing hands doesn’t mean that it’s authorized.  It just means that
>> the token has been leaked to an unauthorized party.****
>>
>> ** **
>>
>>                                                                 -- Mike**
>> **
>>
>> ** **
>>
>> *From:* Nat Sakimura [mailto:sakimura at gmail.com]
>> *Sent:* Thursday, March 28, 2013 4:51 PM
>> *To:* Mike Jones
>> *Cc:* Tim Bray; openid-specs-ab
>>
>> *Subject:* Re: [Openid-specs-ab] OpenID Connect and Identity Delegation**
>> **
>>
>> ** **
>>
>> Which is not the case that it may sometime change the hand. The name
>> bearer suggests otherwise as well. Bearer is whoever has it. ****
>>
>> ** **
>>
>> From Oxford Dictionary: ****
>>
>> ** **
>>
>>  *1*a person or thing that carries or holds something:****
>>
>> *2*a person who presents a cheque or other order to pay money:****
>>
>>  ** **
>>
>> And here is a description of "bearer bond" from wikipedia: ****
>>
>> ** **
>>
>>  A *bearer bond* is a debt security issued by a business entity, such as
>> a corporation, or by a government. It differs from the more common types of
>> investment securities in that it is unregistered – no records are kept of
>> the owner, or the transactions involving ownership. Whoever physically
>> holds the paper on which the bond is issued owns the instrument<http://en.wikipedia.org/wiki/Financial_instrument>.
>> This is useful for investors <http://en.wikipedia.org/wiki/Investor> who
>> wish to retain anonymity. Recovery of the value of a bearer bond in the
>> event of its loss, theft, or destruction is usually impossible. ****
>>
>>  ** **
>>
>> At the same time, bearer is more privacy preserving in some sense. In a
>> "registered token", i.e., token with the "azp", it is impossible to hide
>> who is presenting it. ****
>>
>> ** **
>>
>> Nat****
>>
>>
>> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130328/8ce8d411/attachment.html>


More information about the Openid-specs-ab mailing list