Subject: [OAUTH-WG] OAUTB for Access Token in Implicit Grant

From: [email-masked]
Date: Mon, 14 May 2018 14:46:52 +0200

Dear all,
We are currently modeling part 1 and part 2 of the OpenID Financial API 
in the FKS Web Model and have a few questions regarding the OAuth 2.0 
Token Binding.
In section 3.1. of draft-ietf-oauth-token-binding-06, it is not very 
clear how an Access Token issued from the Authorization Endpoint is 
Token Bound. Is this intended to be the same as an AC issued for a web 
server client? It seems that the user-agent sends both the Provided and 
Referred Token Bindings to the AS, which means that the AS can bind the 
Access Token to the Referred Token Binding, which is the Token Binding 
between the user-agent and the client.
However, the Access Token is not used by the user-agent, which means 
that the client can only send the Token Binding ID used by the 
user-agent (which essentially is the public key) to the Resource Server.
Is this the intended flow of the Token Binding? Because the first 
paragraph of 3.1 says that the "Token Binding ID of the client's TLS 
channel to the protected resource is sent with the authorization request 
as the Referred Token Binding ID", but we assume that the user-agent 
reveals the TB-ID of its own channel to the client.
Best regards,
Pedram Hosseyni

---

From: Brian Campbell <[email-masked]>
Date: Mon, 14 May 2018 16:22:54 -0600

Typically when an access token is issued via the implicit grant directly
from the authorization endpoint, it is for a client that is running as
script in the user-agent. The AS binds the access token to the referred
token binding, which would be the token binding between the user-agent
(where the client is) and the protected resource.

It does mean that a hybrid style client couldn't pass the access token from
its script front-end in the user-agent to its server backed (well, it could
pass it but the server side couldn't use it because of the binding).

On Mon, May 14, 2018 at 6:46 AM, <[email-masked]> wrote:

> Dear all,
>
> We are currently modeling part 1 and part 2 of the OpenID Financial API in
> the FKS Web Model and have a few questions regarding the OAuth 2.0 Token
> Binding.
>
> clear how an Access Token issued from the Authorization Endpoint is Token
> Bound. Is this intended to be the same as an AC issued for a web server
> client? It seems that the user-agent sends both the Provided and Referred
> Token Bindings to the AS, which means that the AS can bind the Access Token
> to the Referred Token Binding, which is the Token Binding between the
> user-agent and the client.
> However, the Access Token is not used by the user-agent, which means that
> the client can only send the Token Binding ID used by the user-agent (which
> essentially is the public key) to the Resource Server.
>
> channel to the protected resource is sent with the authorization request as
> the Referred Token Binding ID", but we assume that the user-agent reveals
> the TB-ID of its own channel to the client.
>
> Best regards,
> Pedram Hosseyni
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Daniel Fett <[email-masked]>
Date: Wed, 23 May 2018 18:27:19 +0200

Thanks Brian! Pedram and I are still not completely sure whether we
fully understand the setting here...

Am 15.05.18 um 00:22 schrieb Brian Campbell:
> Typically when an access token is issued via the implicit grant
> directly from the authorization endpoint, it is for a client that is
> running as script in the user-agent. The AS binds the access token to
> the referred token binding, which would be the token binding between
> the user-agent (where the client is) and the protected resource. 
>
> It does mean that a hybrid style client couldn't pass the access token
> from its script front-end in the user-agent to its server backed
> (well, it could pass it but the server side couldn't use it because of
> the binding).

Section 3.1 says "For access tokens returned directly from the
authorization endpoint,
   such as with the implicit grant defined in Section 4.2 of OAuth 2.0
   [RFC6749], the Token Binding ID of the client's TLS channel to the
   protected resource is sent with the authorization request as the
   Referred Token Binding ID in the "Sec-Token-Binding" header, and is
   used to Token Bind the access token."

Just to clarify: This implies that there must be an HTTP(S) request from
the browser to the protected resource which then gets redirected to the
authorization endpoint. Is that correct?

- Daniel

-- 
SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universitätsstraße 38 - 70569 Stuttgart - Room 2.434

---

From: Brian Campbell <[email-masked]>
Date: Thu, 24 May 2018 15:57:43 -0600

Yeah, that's what is implied. At least given the way that
https://tools.ietf.org/html/draft-ietf-tokbind-https provides to signal to
the client to reveal the Referred Token Binding.

I've heard that there's some potential for the Fetch spec to provide some
APIs or controls around Token Binding, which might facilitate other ways of
getting the Referred Token Binding into a request. But I don't know the
details or likelihood or timeline. And whatever form that takes may or may
not facilitate other options for 'front-channel' requests to the
authorization endpoint.

---

From: Daniel Fett <[email-masked]>
Date: Fri, 25 May 2018 17:56:35 +0200

Ok, thanks!

- Daniel

Am 24.05.18 um 23:57 schrieb Brian Campbell:
> https://tools.ietf.org/html/draft-ietf-tokbind-https provides to
> signal to the client to reveal the Referred Token Binding.
>
> I've heard that there's some potential for the Fetch spec to provide
> some APIs or controls around Token Binding, which might facilitate
> other ways of getting the Referred Token Binding into a request. But I
> don't know the details or likelihood or timeline. And whatever form
> that takes may or may not facilitate other options for 'front-channel'
> requests to the authorization endpoint.
>
>
> On Wed, May 23, 2018 at 10:27 AM, Daniel Fett
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Just to clarify: This implies that there must be an HTTP(S)
>     request from the browser to the protected resource which then gets
>     redirected to the authorization endpoint. Is that correct?
>
>
>  
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited.  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./