Re: [OAUTH-WG] Mobile Native apps and renewing access tokens

[David Waite]

The offline_access scope is defined as part of OpenID Connect, not as part of 
OAuth. There is no requirement that offline_access scope be the only way to 
have a refresh token issued, although some implementations have chosen to do 
this. My interpretation is that the offline_access is a partial misnomer - the 
user is only ‘offline’ in the sense of whether they currently have an 
authenticated session with the IDP.

The reason many OIDC implementations try to not return refresh tokens is that 
they want to have all authentication decisions flow through the user agent as 
potentially interactive. You can track user authentication within a refresh 
token, but this adds complications such as requiring persistent state within 
the application.

The question is whether your app cares about current user authentication at the 
IDP. If your application either:
- Uses IDP authentication more as a registration/account recovery to a local 
application account
- Doesn’t care about IDP authentication but is just using the token for 
authorization purposes

Then there isn’t a reason to go back through the web-based authentication 
process. Just do what you need to get a refresh token within the TOS of the IDP 
and go with that.

IMO, the value of knowing active IDP authentication is reduced for mobile use 
cases, because (rightly or wrongly) users are expected to control access to the 
native applications through screen locks, passcodes, and biometrics. The 
primary user authentication is local and implicit in being able to open the 
app. The UX expectation is that further authentication challenges by remote 
services are to be done only as needed for their own CYA.

If however you do want to rely on the IDP authentication, you’ll need to play 
within the process of the IDP chosen. Don’t request offline access, hope they 
give you a refresh token to use, and if not you’ll be popping up a browser pane 
(with a user consent on iOS 11+) every time the access token expires so the IDP 
can determine if the authentication still holds.

And hope in the future that in the absence of offline_access, the IDP give a 
refresh token tracking the user authentication session, in order to reduce the 
frequency users are sent through that browser pane.

-DW

> On Sep 5, 2018, at 9:29 AM, Ron Alleva  wrote:
> 
> Hi all,
> 
> I was looking around for guidance around how to refresh access tokens on 
> native mobile experiences. 
> 
> Suppose we’re using a normal OAuth auth code flow with a mobile app (Chrome 
> custom tabs/ASWebAuthenticationSession and all). Also, want to reduce the 
> interruptions to the end user. 
> 
> In general, it seems like refresh token is not the tool for the job, as it 
> generally implies offline_access, when the user is not there. So if the user 
> signed out of their identity provider, I would not want them to be able to 
> get a new access token.
> 
> Via normal web flow, the “prompt=none” ability is available (called Silent 
> Authentication by Auth0), so the refresh can be done in the background, 
> without ever bothering the user at all if they are still logged in. I don’t 
> think this is possible with a chrome custom tab or iOS equivalent, even if 
> the user never needs to enter their password.
> 
> Is there some type of similar flow for native mobile applications? It seems 
> like most of the suggestions out there refer to just using the refresh 
> tokens. Also, another note, SMART on FHIR seems to introduce the concept of 
> “online_access”, which seems to indicate a refresh token that is tied to an 
> authentication session. That also seems interesting to me.
> 
> So anyway, is there any general guidance? Is everyone just using refresh 
> tokens? Some combination of long access tokens and longer web authentication 
> sessions?
> 
> Thanks in advance,
> 
> Ron
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt

[Brian Campbell]

Thanks for the review, George. I'll add some more color to the text around
the RFC 6749 references/links so one can know what they are without having
to follow the reference (or have RFC 6749 memorized :)).  And adding some
more guidance/discussion about the interplay of scope and resource is
already on my todo list for the next revision based on feedback/requests
from several other folks. The content of the draft is long overdue for some
updates but I just haven't had the chance to do the work yet. I don't think
there's anything that precludes using a logical URI for a resource but I
think the text should be focused on the nominal case of the resource
indicating the location of the resource.







On Thu, Aug 30, 2018 at 1:00 PM George Fletcher  wrote:

> Comments...
>
> I found the following paragraph a little confusing:
>
>When an access token will be returned from the authorization
>endpoint, the "resource" parameter is used in the authorization
>request to the authorization endpoint as defined in Section 4.2.1 
> 
>  of
>OAuth 2.0 [RFC6749 ].  An example of 
> an authorization request where
>the client tells the authorization server that it wants a token for
>use at "https://rs.example.com/;  is shown in 
> Figure 1 below.
>
> I don't have RFC 6749 memorized to the level of section numbers:) I would 
> recommend calling out that for the co
>
> I don't have RFC 6749 memorized to the level of section numbers so it took
> a bit to realize you were talking about Implicit and "Hybrid" flows.
> Suggested text addition...
>
>When an access token will be returned from the authorization
>endpoint (such as the Implicit flow [Section 4.2.1 
> 
>  of
>OAuth 2.0 [RFC6749 ]]), the 
> "resource" parameter is used in the authorization
>request to the authorization endpoint.  For OAuth flows that only return an
>access token from the token endpoint, the resource parameter MUST NOT be
>used in the authorization request. An example of an authorization request 
> where
>the client tells the authorization server that it wants a token for
>use at "https://rs.example.com/;  is shown in 
> Figure 1 below.
>
>
> Or something like that.
>
> Also, should there be some discussion regarding using logical URIs for
> resources rather than requiring a specific physical path? The AS can always
> translate the resource URI to a physical endpoint if necessary.
>
> Finally, should we define more guidance on the separate of scopes and
> resource indicators? For example, for an instant messaging services there
> might be scopes of "sendIM", "readBuddyList", "adminAccount". And then the
> resource indicator might be https://api.im.example.com. Given the client
> is requesting a token with a scope of "sendIM" is it really necessary to
> also specify a resource indicator of "https://api.im.example.com;
>  as the AS could probably infer that from the
> scope parameter.
>
> Thanks,
> George
>
> On 8/3/18 11:39 PM, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : Resource Indicators for OAuth 2.0
> Authors : Brian Campbell
>   John Bradley
>   Hannes Tschofenig
>   Filename: draft-ietf-oauth-resource-indicators-00.txt
>   Pages   : 8
>   Date: 2018-08-03
>
>
>
>

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

Re: [OAUTH-WG] Mobile Native apps and renewing access tokens

[George Fletcher]

I second the suggestion to use refresh_tokens even in an "online_access" 
model. You are correct that most Authorization Servers will grant 
offline_access to mobile apps because that produces a better user 
experience. However, if your requirements prohibit granting 
offline_access to the mobile app that doesn't preclude you from using 
refresh_tokens. Instead, the refresh_token is bound to a server side 
session and when the mobile app makes a refresh_token request and the 
server side session has expired, the refresh_token request fails and the 
mobile app knows it needs to ask the user to re-authenticate.


If tracking server-side sessions is a problem, you can also have the 
Authorization Server issue time-bound refresh_tokens (i.e. the 
refresh_token is only good for 90 minutes). The mobile app then 
refreshes it's access token as often as it needs until the refresh token 
flow fails at which point the mobile app asks the user to re-authenticate.


Hope that helps,
George

On 9/5/18 12:13 PM, Iain McGinniss wrote:
Hi, I'm the maintainer of AppAuth-Android, I've also cc'd William 
Denniss, the maintainer of AppAuth-iOS and the author of the OAuth2 
for Native Apps BCP (BCP 212).


We recommend using the code flow to get a refresh token in order to 
transparently acquire new access tokens as required, along with some 
other recommendations in the BCP. There isn't a feasible alternative 
within the spec for mobile apps, as repeatedly surfacing a browser tab 
is too disruptive to the UX, and using an embedded web view is bad 
security practice.


Whether the refresh token is "bound" to the lifetime of some other 
revocable session is implementation specific, but if that 
implementation is under your control you could tie the validity of the 
refresh token to that of a web auth cookie, how recently it has been 
used, etc. There is no reliable way of detecting browser state within 
an app without the user interacting with a browser tab, unfortunately.


On Wed, Sep 5, 2018, 08:30 Ron Alleva > wrote:


Hi all,

I was looking around for guidance around how to refresh access
tokens on native mobile experiences.

Suppose we’re using a normal OAuth auth code flow with a mobile
app (Chrome custom tabs/ASWebAuthenticationSession and all). Also,
want to reduce the interruptions to the end user.

In general, it seems like refresh token is not the tool for the
job, as it generally implies offline_access, when the user is not
there. So if the user signed out of their identity provider, I
would not want them to be able to get a new access token.

Via normal web flow, the “prompt=none” ability is available
(called Silent Authentication by Auth0), so the refresh can be
done in the background, without ever bothering the user at all if
they are still logged in. I don’t think this is possible with a
chrome custom tab or iOS equivalent, even if the user never needs
to enter their password.

Is there some type of similar flow for native mobile applications?
It seems like most of the suggestions out there refer to just
using the refresh tokens. Also, another note, SMART on FHIR seems
to introduce the concept of “online_access”, which seems to
indicate a refresh token that is tied to an authentication
session. That also seems interesting to me..

So anyway, is there any general guidance? Is everyone just using
refresh tokens? Some combination of long access tokens and longer
web authentication sessions?

Thanks in advance,

Ron
___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Mobile Native apps and renewing access tokens

[Iain McGinniss]

Hi, I'm the maintainer of AppAuth-Android, I've also cc'd William Denniss,
the maintainer of AppAuth-iOS and the author of the OAuth2 for Native Apps
BCP (BCP 212).

We recommend using the code flow to get a refresh token in order to
transparently acquire new access tokens as required, along with some other
recommendations in the BCP. There isn't a feasible alternative within the
spec for mobile apps, as repeatedly surfacing a browser tab is too
disruptive to the UX, and using an embedded web view is bad security
practice.

Whether the refresh token is "bound" to the lifetime of some other
revocable session is implementation specific, but if that implementation is
under your control you could tie the validity of the refresh token to that
of a web auth cookie, how recently it has been used, etc. There is no
reliable way of detecting browser state within an app without the user
interacting with a browser tab, unfortunately.

On Wed, Sep 5, 2018, 08:30 Ron Alleva  wrote:

> Hi all,
>
> I was looking around for guidance around how to refresh access tokens on
> native mobile experiences.
>
> Suppose we’re using a normal OAuth auth code flow with a mobile app
> (Chrome custom tabs/ASWebAuthenticationSession and all). Also, want to
> reduce the interruptions to the end user.
>
> In general, it seems like refresh token is not the tool for the job, as it
> generally implies offline_access, when the user is not there. So if the
> user signed out of their identity provider, I would not want them to be
> able to get a new access token.
>
> Via normal web flow, the “prompt=none” ability is available (called Silent
> Authentication by Auth0), so the refresh can be done in the background,
> without ever bothering the user at all if they are still logged in. I don’t
> think this is possible with a chrome custom tab or iOS equivalent, even if
> the user never needs to enter their password.
>
> Is there some type of similar flow for native mobile applications? It
> seems like most of the suggestions out there refer to just using the
> refresh tokens. Also, another note, SMART on FHIR seems to introduce the
> concept of “online_access”, which seems to indicate a refresh token that is
> tied to an authentication session. That also seems interesting to me.
>
> So anyway, is there any general guidance? Is everyone just using refresh
> tokens? Some combination of long access tokens and longer web
> authentication sessions?
>
> Thanks in advance,
>
> Ron
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Non-repudiation for API requests and responses

[Dave Tonge]

Thanks James - definitely an interesting case.
I'd be sorry to see ACME and other APIs go down the route of POSTing base64
encoded blobs for all API interactions.


On Mon, 3 Sep 2018 at 14:56, Manger, James 
wrote:

> ACME 
> (Automatic Certificate Management Environment) [draft-ietf-acme-acme] (eg
> Lets Encrypt CA) is an interesting case. It POSTs JWS objects using the
> Flattened JSON Serialization with a "url" member in the protected header.
> It is likely to use the same scheme (POST a JWS) to replace GET methods as
> well.
>
>
>
> --
>
> James Manger
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Non-repudiation for API requests and responses

[Samuel Erdtman]

Then I’ll post an update within a ~week.

There is one thing that could make implementing even simpler (from my
experience). That is how to handle multiple signatures. Today the
specification supports sharing of headers between signatures. If signatures
instead are completely independent and put in an array at the top level
cleartext_signature attribute one could just do a minor change to existing
implementations to support cleartext signatures.
On Wed, 5 Sep 2018 at 15:54, Dave Tonge  wrote:

> Hi Samuel,
>
> Thanks for the reply, I would definitely be interested in an updated draft.
> Both the signing spec and the canonicalization spec seem a lot simpler
> than JSON-LD.
> It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs
>
> Thanks
>
> Dave
>
> On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman  wrote:
>
>> Hi
>>
>> As one of the authors of draft-erdtman-jose-cleartext-jws I definitely
>> think this is the way to go. The initial use case was to sign transaction
>> requests and responses, and as was mentioned in previous emails it is very
>> much desirable to not obfuscate the payload with base64 encoding.
>>
>> The current draft just expired but if we have found interest I would be
>> more than willing to post an update. I was supposed to do so earlier but
>> since it has been hard to find a home for the work (an interested WG) it
>> has not be top of my proirity list.
>>
>> With the potential update we (I and the co authors) intended to do some
>> cleanup and one significant change. We think we should move from ES6
>> serialization to canonicalization based on
>> draft-rundgren-json-canonicalization-scheme
>> .
>> After a lot of research and emails we have come to the conclusion that it
>> would be easier to get buy in for this method than to get languages to
>> support ES6 compatible serialization.
>> draft-rundgren-json-canonicalization-scheme has the additional benefit that
>> non-intrusive modifications such as attribute reordering would not make
>> ruin this signature which was the case with ES6 serialization (and we could
>> avoid some minor ES6 quirks).
>>
>> Implementations for the draft-rundgren-json-canonicalization-scheme
>> canonicalization schema is available in JavaScript
>> , .NET
>> ,
>> Java
>> ,
>> and Python
>> .
>> Anders is currently putting a lot of effort into the canonicalization to
>> make sure it is stable, and it has been reviewed by several people
>> knowledgeable in JSON.
>>
>> When it comes to draft-erdtman-jose-cleartext-jws implementations, I have
>> done one in JavaScript (I modified an existing JOSE implementation in a few
>> hours) and Anders has done a Java implementation (at least). The examples
>> in the specification was created and validated with different
>> implementations.
>>
>> I know canonicalization is a scary thing if you have worked with
>> canonicalization of XML, but I can tell you canonicalization of JSON is not
>> even close to that complex.
>>
>> Best regards
>> //Samuel Erdtman
>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Non-repudiation for API requests and responses

[Dave Tonge]

Hi Samuel,

Thanks for the reply, I would definitely be interested in an updated draft.
Both the signing spec and the canonicalization spec seem a lot simpler than
JSON-LD.
It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs

Thanks

Dave

On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman  wrote:

> Hi
>
> As one of the authors of draft-erdtman-jose-cleartext-jws I definitely
> think this is the way to go. The initial use case was to sign transaction
> requests and responses, and as was mentioned in previous emails it is very
> much desirable to not obfuscate the payload with base64 encoding.
>
> The current draft just expired but if we have found interest I would be
> more than willing to post an update. I was supposed to do so earlier but
> since it has been hard to find a home for the work (an interested WG) it
> has not be top of my proirity list.
>
> With the potential update we (I and the co authors) intended to do some
> cleanup and one significant change. We think we should move from ES6
> serialization to canonicalization based on
> draft-rundgren-json-canonicalization-scheme
> .
> After a lot of research and emails we have come to the conclusion that it
> would be easier to get buy in for this method than to get languages to
> support ES6 compatible serialization.
> draft-rundgren-json-canonicalization-scheme has the additional benefit that
> non-intrusive modifications such as attribute reordering would not make
> ruin this signature which was the case with ES6 serialization (and we could
> avoid some minor ES6 quirks).
>
> Implementations for the draft-rundgren-json-canonicalization-scheme
> canonicalization schema is available in JavaScript
> , .NET
> , Java
>
> ,
> and Python
> .
> Anders is currently putting a lot of effort into the canonicalization to
> make sure it is stable, and it has been reviewed by several people
> knowledgeable in JSON.
>
> When it comes to draft-erdtman-jose-cleartext-jws implementations, I have
> done one in JavaScript (I modified an existing JOSE implementation in a few
> hours) and Anders has done a Java implementation (at least). The examples
> in the specification was created and validated with different
> implementations.
>
> I know canonicalization is a scary thing if you have worked with
> canonicalization of XML, but I can tell you canonicalization of JSON is not
> even close to that complex.
>
> Best regards
> //Samuel Erdtman
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth