According to https://www.slideshare.net/gauravroy/stateless-auth-using-oauth2-jwt slide #55 we are missing some standard claims in our generated JWT. Add them to the normalizer TokenEntityNormalizer.php.

You can also find the claims in https://tools.ietf.org/html/rfc7519#section-4.1.

help

CommentFileSizeAuthor
#2 2017-09-24 13-06-12.png98.51 KBe0ipso

Comments

e0ipso created an issue. See original summary.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Issue summary: View changes
StatusFileSize
new 2017-09-24 13-06-12.png98.51 KB
skyredwang’s picture

skyredwang
Location Shanghai
commented
Assigned: e0ipso » Unassigned

Two questions:

1. Do we want to go stateless? If so, we can get rid off the entire $token_entity, including its creation and validation.

My understanding is "why not?". Removing this Drupal specific $token_entity simplifies things and increase performance.

2. According to https://www.slideshare.net/gauravroy/stateless-auth-using-oauth2-jwt slide #55, the token expiration claim shall use "exp" instead of "expire", which is already in use.

If we change the keyword, then we would have incompatibility issues with existing clients; if we add a duplicate "exp", then it's not super elegant, and confusing.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Status: Active » Needs work

@skyredwang thanks for your thoughtful comments.

1. Do we want to go stateless? If so, we can get rid off the entire $token_entity, including its creation and validation.

I'm not opposed to it. In fact there are simpler implementations that do just that. However there are challenges that you'll need to figure out, like revoking tokens that have been issued. The PHP library we are using assumes there is a persistent store for tokens due to these things.

I'm open to suggestions though.

2. According […] shall use "exp" instead of "expire", which is already in use.

I think it's OK to rename to "exp". There was never explicit support for JWT because it was not standard compliant. This issue should fix that.

skyredwang’s picture

skyredwang
Location Shanghai
commented
Version: 8.x-2.x-dev » 8.x-3.x-dev

However there are challenges that you'll need to figure out, like revoking tokens that have been issued. The PHP library we are using assumes there is a persistent store for tokens due to these things.

I didn't think of this. It sounds reasonable. Citing from page 79 on https://www.slideshare.net/alvarosanchezmariscal/stateless-authenticatio...

When going stateless, it's impossible to invalidate JWTs before they expire. Alternatives: .......

Since statefull $token_entity management is already in place. I'd like to not change it, since it provides this extra feature.

The work for this issue is indeed what the original summary says, which should be straightforward, given the second answer from #4

alan_blake’s picture

alan_blake commented

1. Post to `oauth/token` and the result is:

{
    "token_type": "Bearer",
    "expires_in": 300,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6IjA1MTY3ODg1ZWU2MzcxZTkyOTA5N2E1NzBhOTg5OWE2YTU1OTZiMjVmOTI0NWExNDUzZjkxNTllNTAwNTQ3M2IyYjRiZTZkMGIyMTIzYzc0In0.eyJhdWQiOiJkM2FjN2MwZS0yMjg2LTQxZDEtOTE4MC1kOWE2Zjc2NjQ3MGQiLCJqdGkiOiIwNTE2Nzg4NWVlNjM3MWU5MjkwOTdhNTcwYTk4OTlhNmE1NTk2YjI1ZjkyNDVhMTQ1M2Y5MTU5ZTUwMDU0NzNiMmI0YmU2ZDBiMjEyM2M3NCIsImlhdCI6MTUxMTk1MjMzNiwibmJmIjoxNTExOTUyMzM2LCJleHAiOjE1MTE5NTI2MzYsInN1YiI6IjEiLCJzY29wZXMiOlsiYXV0aGVudGljYXRlZCIsIm9hdXRoX2dyYW50X3JvbGUiXX0.aKzLmEwRAUURzX2SwNFkwNsV82WVtADxKKfZVSSUaqQcDL7C7RWobQxlC2pbS7lVzxUV0uUqcMz8orgHpOv8D7PmT8qGQlaNR6iF48LNITyDtDeZXXUc_aRWrjDvIp8vyVSyE3ie72vhYIUOg8AWJgOyWZ51C7CluY2JJ8ore8e8dsyyk4NReRqDy2hWlFcTcHzNquLz21MIGKuQ2HLwjXX4z8v6-UWjwHgO1gAMNeI-xQjYaVbAlZRyvfw08Md-W7OkVYbXJYrjzOr_gthpWDuL69rEXdcYs_Kbv1jerYeMMRo-F14gnKKpVaDdodAbuqbzr_2-loXARTTivu3UOQ",
    "refresh_token": "def502002d9795d5befb7d3454f2b47b9ec60e205168bd9bd8b4f9da0464549c2490d563e5116c6f587ad97f4421a9f3f4a71b88c14110206792d570e7373cd29a6af498e021f0505359eaf874a8dba63e4f4840ace1a15e4e0a61a87522ac327aa89d4fc3b74607e1c805586f8b400cd8c899abe460535b387276a66d5b730ceb3e951c3788cbc666312d1be0e49ac5b92ab168b837155c1e0e33c42f1ade9fda0a648c8fb0c24adb98dde4409cd81d211782f7e23a6453cacd11b666dd7d06b58ca2b1d7320c8563267795f25cb43ac0ab8d194da7f9237e276b27fdd9e5ffa3a40ec13a972c2ccab506440a2693618be7992dd22a71f988a202301189f7b712d6f07366ad8200d8728be57e10fd996214a5a4c12a86f017444ba494d75574f3ba7a29a47e278acca83d86abc82374bd6dd3f204e5c15f307fd632267d00bb46dac89cbe2532fe6e4b3fa41b0c52eac2fc5dcebef7ccaf43875a7f092bdbd40da69bc620c061c08747ac0008b4cfa6b9a52d3b88c54a52007fede6cb46ce4a916296ce4dd62909a59cd7bd05ca34bd23085c3e7283cb057543d376cd2f958d1f7272f88314e459"
}

2. decode access_token on https://jwt.io/ and result is

header:
{
  "typ": "JWT",
  "alg": "RS256",
  "jti": "da72abe35bb1d12d33d2f89e35e9fb93c3ef23d4852aaa74fee7289e17ef3cc55af01a8233310d80"
}

payload:
{
  "aud": "d3ac7c0e-2286-41d1-9180-d9a6f766470d",
  "jti": "da72abe35bb1d12d33d2f89e35e9fb93c3ef23d4852aaa74fee7289e17ef3cc55af01a8233310d80",
  "iat": 1511938749,
  "nbf": 1511938749,
  "exp": 1511939049,
  "sub": "",
  "scopes": [
    "authenticated",
    "oauth_grant_role"
  ]
}

3. Check the claims, only missing the "iss" (Issuer) Claim (https://tools.ietf.org/html/rfc7519#section-4.1)

Also check the upstream https://github.com/thephpleague/oauth2-server/blob/master/src/Entities/Traits/AccessTokenTrait.php that doesn't claim neither.
If we need this claim, maybe we should fix this on upstream.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Status: Needs work » Closed (works as designed)

Thanks for the investigation @alan_blake. It turns out that the claim is not required after all:

4.1.1.  "iss" (Issuer) Claim

   The "iss" (issuer) claim identifies the principal that issued the
   JWT.  The processing of this claim is generally application specific.
   The "iss" value is a case-sensitive string containing a StringOrURI
   value. **Use of this claim is OPTIONAL.**

https://tools.ietf.org/html/rfc7519#section-4.1