Subject: [OAUTH-WG] How can client react to access token not-before errors

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 1 Feb 2016 11:36:27 +0000

Hi

Access tokens (particularly JWT-based) may have a not before property 
set - for example, a token introspection response may report an 'nbf' 
property.

How can a client react to the error related to using the access token 
too early ?

Typically a client would attempt to refresh a token if it has been 
rejected by RS, but in the case of NBF related errors it can become a 
cycle - refresh - get a new token - try it, too early, repeat...

I think for RS reporting 503 with Retry-After, instead of 400/401, would 
be the right way to handle NBF errors.

Thanks, Sergey

---

From: William Denniss <[email-masked]>
Date: Mon, 1 Feb 2016 12:21:11 -0800

On Fri, Jan 29, 2016 at 3:22 PM, Mike Jones <[email-masked]>
wrote:

> Do the PKCE authors want to make a concrete proposal for how to represent
> this in discovery metadata?
>

We don't need to represent this property in the discovery metadata.

All non-confidential clients should be using PKCE (and in the draft native
apps best practice, we say it's a MUST
<https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-01#section-7.2>
if
you want to follow the BCP).  It's OK to send PKCE to a server that doesn't
support PKCE (assuming standards compliance, they won't error on unknown
params), and now we have a way that clients can discover PKCE support and
send it only those those ASes who disclose this.

If a server decides to fail all non-PKCE requests for non-confidential
clients (which is fine), indicating this in discovery actually doesn't add
a whole lot.  Because if the client knows about PKCE it should have been
sending it based on code_challenge_methods_supported anyway, and if it
doesn't know about PKCE then it will always fail, discovery or not.

The thing is, there is no reason for a public client to *not* send PKCE if
the server indicates PKCE support, but then marks it as optional through
this mechanism.  If the client knows PKCE it should just always send PKCE –
so knowing that the request would succeed even if it didn't doesn't add any
value, and may cause harm.

>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *John Bradley
> *Sent:* Friday, January 29, 2016 6:11 AM
> *To:* Nat Sakimura <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] OAuth Discovery metadata values added for
> revocation, introspection, and PKCE
>
>
>
> The only problem with that is the client may only require it for some
> types of clients (public) or response types.
>
>
>
> It may need to be finer grained than that, or define it as required for
> all public clients using the token endpoint.
>
>
>
> John B.
>
>
>
>
>
> On Jan 29, 2016, at 10:15 AM, Nat Sakimura <[email-masked]> wrote:
>
>
>
> Good question.
>
> It's probably a good idea to be able to advertise this policy in the
> discovery.
>
> Perhaps in the line of
>
> pkce_required or rfc7636_required?
> The value should be Boolean.
>
> Nat from iPhone
>
> 2016年1月29日(金) 21:23 Vladimir Dzhuvinov <[email-masked]>:
>
> Thanks Mike, the updated spec looks good!
>
> I have a question related to PKCE:
>
> The PKCE spec seems to imply that an AS may require public clients to use
> a code challenge:
>
> https://tools.ietf.org/html/rfc7636#section-4.4.1
>
> If an AS has such a policy in place, how is this to be advertised? Or is
> that supposed to the enforced when the client gets registered (there are no
> reg params for that at present)?
>
> On 28/01/16 19:27, Mike Jones wrote:
>
> The OAuth Discovery specification has been updated to add metadata values for revocation<http://tools.ietf.org/html/rfc7009> <http://tools.ietf.org/html/rfc7009>, introspection<http://tools.ietf.org/html/rfc7662> <http://tools.ietf.org/html/rfc7662>, and PKCE<http://tools.ietf.org/html/rfc7636> <http://tools.ietf.org/html/rfc7636>.  Changes were:
>
>
>
> *       Added "revocation_endpoint_auth_methods_supported" and "revocation_endpoint_auth_signing_alg_values_supported" for the revocation endpoint.
>
>
>
> *       Added "introspection_endpoint_auth_methods_supported" and "introspection_endpoint_auth_signing_alg_values_supported" for the introspection endpoint.
>
>
>
> *       Added "code_challenge_methods_supported" for PKCE.
>
>
>
> The specification is available at:
>
>
>
> *       http://tools.ietf.org/html/draft-jones-oauth-discovery-01
>
>
>
> An HTML-formatted version is also available at:
>
>
>
> *       http://self-issued.info/docs/draft-jones-oauth-discovery-01.html
>
>
>
>                                                           -- Mike
>
>
>
> P.S.  This note was also published at http://self-issued.info/?p=1531 and as @selfissued<https://twitter.com/selfissued> <https://twitter.com/selfissued>.
>
>
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
>
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>