Subject: [OAUTH-WG] allowing offline access for native app & its backend server

From: nov matake <[email-masked]>
Date: Sat, 21 Nov 2015 21:55:49 +0900

Hi OAuthers,

I’m thinking the way to issue refresh tokens both to native app and its backend server at same time.
I have 2 ideas currently.

1. including 2 audience in a single authorization code, and allow using the code once per the audience.
2. issuing 2 code one for native app, one for backend server.

1st way means code can be used twice, so it can break RFC6749.
2nd way means defining another code (ex. code_for_backend etc.)

Does someone has implementation supporting such use-case?

—
nov

---

From: John Bradley <[email-masked]>
Date: Sat, 21 Nov 2015 11:00:33 -0300

There is a missing step in this flow that also needs to be considered, and that is how the app authenticates to the backend server.

In the Google case they are providing a JWT/id_token to the client from the token endpoint for the client to use for it’s authentication to it’s backend.

It would not be a huge step to have the backend then use token exchange along with it’s credentials to exchange that for a refresh token.

I can see giving out two codes and we have discussed that in the past.  

This topic should perhaps be added to the list of things for rechartering.   There are a lot of interactions and posable security side effects that need to be looked at.

John B.

> On Nov 21, 2015, at 9:55 AM, nov matake <[email-masked]> wrote:
> 
> Hi OAuthers,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: nov matake <[email-masked]>
Date: Sat, 21 Nov 2015 23:12:37 +0900

Thanks John,

I’m also OK to exchange id_token (from token endpoint) with access/refresh token using OAuth assertion flow etc., if the AuthZ server is OpenID Connect IdP.
(In my case, AuthZ server would be OIDC IdP)

ps.
I also want to use PKCE for the native app & its backend combination case.
So id_token given from authorization endpoint won’t be my solution.

> On Nov 21, 2015, at 23:00, John Bradley <[email-masked]> wrote:
>