I get your 1st party use case and if you think about a company that
might have multiple endpoints on different domains that provide API
services all invoked by a mobile app... requiring the mobile app to
effectively downscope (or resource indicator bind) tokens means a lot of
chatter between the mobile app to the AS to obtain appropriate tokens.
And all this over a connection that does have latency issues.
That said, having a single token that is authorized to access all those
services has it's own risks.
I'm not sure about a structure like...
https://user.example.com
scope: profile
https://mail.example.com
scope: mail-write
https://cal.example.com
scope: calendar-write
User Managed Access (UMA) [1] explicitly defines this structure but it's
not embedded in the UMA access token.
[1]
https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html#permission-endpoint
I suppose a need to support multiple audiences within a given access
token kind of necessitates the need to bind the scopes with the
audience/resource.
On 4/4/19 1:34 PM, Vittorio Bertocci wrote:
I think for most implementations this would amount to... define an
audience that covers all the resource services where the access
token can be returned and set that as the audience (e.g.
urn:x-mydomain:apis). Which is perfectly legal but maybe not in
the spirit of the spec:) I am receiving feedback from developers
that binding access tokens narrowly to the resource where they
will be presented is concerning from a chattiness perspective
(latency issues) and general load on the deployed AS infrastructure.
This is an interesting point. In my experience, the main boundary used
to define a resource is either reflecting an underlying, *actual*
resource that exists independently of the API facade slapped on top of
it (say a VM) or it is the context within a certains et of scopes
makes sense (say an API facading access to a bunch of documents).
Some of that criterion is reflected in the rationale for sigle value
audiences. Do you think it should be made more explicit? Perhaps in a
dedicated section?
[rest of thread snipped]
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
