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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
