[Openid-specs-native-apps] Returning a second Code

Mike Varley mike.varley at securekey.com
Thu Nov 27 15:18:45 UTC 2014


I John,

Sorry I missed the F2F, but I also see value in the Token Endpoint returning codes for client back ends to exchange for an AT/RT.

Unfortunately I am confused by your question; are you asking if a new spec should be developed around this idea, or if it should be wrapped into an existing spec?

Sorry for the confusion.

MV


On Nov 26, 2014, at 5:48 PM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:

At the F2F meetings Google stated that there is a use case to return a OAuth Code / or something like it to the client so that it could be passed to the client’s back end to later have it exchanged for a AT/RT.

The logic is that the code for the backend would be to a confidential client and may have additional scopes beyond what the native app has access to.

This is likely useful outside the strict scope of NAPPS so should probably start life as a separate document if we want to take this on.

If we are using a native TA with code then we also have to consider how we get a code based on a refresh token, or use the authorization endpoint each time.

In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution we have added a token_type to the token_endpoint request. (that lets a client specify that it wants a Proof of possession token dynamically)

In the same spec we also add audience “aud” to the request.

We could extend that to define a code token type that returns a code for a aud, as a fairly generic method.

The missing part would be to add the SPOP code_challange to the token_endpoint request.

This also has the side benefit of letting the native app and the backend server use https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution when exchanging code to establish a key for POP tokens.

I think the same method would also work for id_tokens as well rather than trying to overload a scope value.

So I guess the extension to the token endpoint for returning code and/or id_tokens could be one or two specs, but there is a lot of overlap so perhaps one to start?

Thoughts.

John B.

_______________________________________________
Openid-specs-native-apps mailing list
Openid-specs-native-apps at lists.openid.net<mailto:Openid-specs-native-apps at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-native-apps

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20141127/ef6d272d/attachment.html>


More information about the Openid-specs-native-apps mailing list