|
Hi,
I have some trusted clients set up to use client_credentials token grant.
I'll like to set their tokens not to expire.
How do I achieve this?
|
|
|
toggle quoted message
Show quoted text
On Thu, Jul 23, 2015 at 11:05 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote: Hi,
I have some trusted clients set up to use client_credentials token grant.
I'll like to set their tokens not to expire.
How do I achieve this?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Thanks Filip.
However, everytime I set that (for example, I set it to 2542838400), I get
this:
"The request sent by the client was syntactically incorrect."
That's December 31st 2050 when decoded. Is it possible that, that number is
too large?
toggle quoted message
Show quoted text
|
|
|
public static final intMAX_VALUE < http://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#MAX_VALUE> 2147483647 that's the largest value you can set. However, I just realized, that if you set this value, the UAA will get an overflow and the int will become negative. so set the value to 315 569 260 that's a 10 year expiration. the computer that retrieved that token won't be around in 10 years so it's a safe number.
On Friday, July 24, 2015, Kayode Odeyemi <dreyemi(a)gmail.com> wrote: Thanks Filip.
However, everytime I set that (for example, I set it to 2542838400), I get
this:
"The request sent by the client was syntactically incorrect."
That's December 31st 2050 when decoded. Is it possible that, that number
is too large?
On Thu, Jul 23, 2015 at 7:09 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','fhanik(a)pivotal.io');>> wrote:
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#register-client-post-oauthclients
access_token_validity - int Optional Value in seconds for how long an
access token is valid for
Set this field to a very large value, like
http://docs.oracle.com/javase/7/docs/api/constant-values.html#java.lang.Integer.MAX_VALUE
On Thu, Jul 23, 2015 at 11:05 AM, Kayode Odeyemi <dreyemi(a)gmail.com
<javascript:_e(%7B%7D,'cvml','dreyemi(a)gmail.com');>> wrote:
Hi,
I have some trusted clients set up to use client_credentials token
grant. I'll like to set their tokens not to expire.
How do I achieve this?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
<javascript:_e(%7B%7D,'cvml','cf-dev(a)lists.cloudfoundry.org');>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
<javascript:_e(%7B%7D,'cvml','cf-dev(a)lists.cloudfoundry.org');>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Filip,
Even when I set the value to 315569260 (this value seems to be lesser than
today though), when I decode the issued token, I get something like this
`"exp":1438209609`.
Is token validity and expiration two different things?
|
|
|
toggle quoted message
Show quoted text
On Wed, Jul 29, 2015 at 4:46 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote: Filip,
Even when I set the value to 315569260 (this value seems to be lesser than
today though), when I decode the issued token, I get something like this
`"exp":1438209609`.
Is token validity and expiration two different things?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Thanks again Filip.
However, here's what I mean,
If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?
line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)
Now the question is why do you have to do expirationTime*1000l since the
token when decoded originally set's this value to 1438209609 (without *
1000l)
Except I'm completely getting this all wrong?
|
|
|
If I set the access_token_validity to 315569260, I'm expecting the token when decoded to read exp: 315569260. If this is not, then is it possible to set the token expiry time? It's a little bit different. access_token_validity is how long the token is valid for from the time of creation. thus we can derive exp (expiration time) = token creation time + access token validity you don't get to set the expiration time, since that doesn't make sense as the clock keeps ticking forward. in your case, having access token validity be 10 years, achieves exactly what you want Filip On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote: Thanks again Filip.
However, here's what I mean,
If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?
line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)
Now the question is why do you have to do expirationTime*1000l since the
token when decoded originally set's this value to 1438209609 (without *
1000l)
Except I'm completely getting this all wrong?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Good. But my apologies. Assume:
creation time = 1438184877
access token validity (set by me) = 315360000
exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276
toggle quoted message
Show quoted text
On Wed, Jul 29, 2015 at 5:43 PM, Filip Hanik <fhanik(a)pivotal.io> wrote: If I set the access_token_validity to 315569260, I'm expecting the token when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?
It's a little bit different.
access_token_validity is how long the token is valid for from the time of
creation. thus we can derive
exp (expiration time) = token creation time + access token validity
you don't get to set the expiration time, since that doesn't make sense as
the clock keeps ticking forward.
in your case, having access token validity be 10 years, achieves exactly
what you want
Filip
On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:
Thanks again Filip.
However, here's what I mean,
If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?
line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)
Now the question is why do you have to do expirationTime*1000l since the
token when decoded originally set's this value to 1438209609 (without *
1000l)
Except I'm completely getting this all wrong?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
exp is expected to be 1753544877 when decoded. Unfortunately, this test fails, as exp reads 1438228276 most likely your client does not have the access token validity setup correctly. See the test case I posted that validates my statements https://github.com/cloudfoundry/uaa/commit/f0c8ba99cf37855fec54b74c07ce19613c51d7e9#diff-f7a9f1a69eec2ce4278914f342d8a160R883On Wed, Jul 29, 2015 at 9:57 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote: Good. But my apologies. Assume:
creation time = 1438184877
access token validity (set by me) = 315360000
exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276
On Wed, Jul 29, 2015 at 5:43 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:
If I set the access_token_validity to 315569260, I'm expecting the token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?
It's a little bit different.
access_token_validity is how long the token is valid for from the time of
creation. thus we can derive
exp (expiration time) = token creation time + access token validity
you don't get to set the expiration time, since that doesn't make sense
as the clock keeps ticking forward.
in your case, having access token validity be 10 years, achieves exactly
what you want
Filip
On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:
Thanks again Filip.
However, here's what I mean,
If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?
line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)
Now the question is why do you have to do expirationTime*1000l since the
token when decoded originally set's this value to 1438209609 (without *
1000l)
Except I'm completely getting this all wrong?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Filip,
Here's my client config:
useraccount
scope: clients.read oauth.approvals openid password.write tokens.read
tokens.write uaa.admin
resource_ids: none
authorized_grant_types: authorization_code client_credentials password
refresh_token
authorities: scim.read scim.userids uaa.admin uaa.resource clients.read
scim.write cloud_controller.write scim.me clients.secret password.write
clients.write openid cloud_controller.read oauth.approvals
access_token_validity: 315360000
autoapprove: true
Gotten from `uaac clients`
I really do not know what else I might be doing wrongly.
Does `test_Token_Expiry_Time()` also cover for client_credentials grant
type? I tried running the test with
`./gradlew test
-Dtest.single=org/cloudfoundry/identity/uaa/mock/token/TokenMvcMockTests`
and placed debuggers in order to view the generated expiration time.
Nothing was printed in the test results.
toggle quoted message
Show quoted text
On Wed, Jul 29, 2015 at 6:11 PM, Filip Hanik <fhanik(a)pivotal.io> wrote: exp is expected to be 1753544877 when decoded. Unfortunately, this test fails, as exp reads 1438228276
most likely your client does not have the access token validity setup
correctly. See the test case I posted that validates my statements
https://github.com/cloudfoundry/uaa/commit/f0c8ba99cf37855fec54b74c07ce19613c51d7e9#diff-f7a9f1a69eec2ce4278914f342d8a160R883
On Wed, Jul 29, 2015 at 9:57 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:
Good. But my apologies. Assume:
creation time = 1438184877
access token validity (set by me) = 315360000
exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276
On Wed, Jul 29, 2015 at 5:43 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:
If I set the access_token_validity to 315569260, I'm expecting the token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?
It's a little bit different.
access_token_validity is how long the token is valid for from the time
of creation. thus we can derive
exp (expiration time) = token creation time + access token validity
you don't get to set the expiration time, since that doesn't make sense
as the clock keeps ticking forward.
in your case, having access token validity be 10 years, achieves exactly
what you want
Filip
On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:
Thanks again Filip.
However, here's what I mean,
If I set the access_token_validity to 315569260, I'm expecting the
token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?
line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)
Now the question is why do you have to do expirationTime*1000l since
the token when decoded originally set's this value to 1438209609
(without * 1000l)
Except I'm completely getting this all wrong?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Start a local server (./gradlew run --info) In another console, the following commands 1. uaac target http://localhost:8080/uaa 2. uaac token client get admin -s adminsecret 3. uaac client add testclient --authorized_grant_types client_credentials --access_token_validity 315360000 --authorities openid -s testclientsecret 4. uaac token client get testclient -s testclientsecret 5. uaac token decode The output from the last command is jti: 7397c7c9-de08-4b33-bd6a-0d248fd983b1 sub: testclient authorities: openid scope: openid client_id: testclient cid: testclient azp: testclient grant_type: client_credentials rev_sig: fbc56677 iat: 1438351964 exp: 1753711964 iss: http://localhost:8080/uaa/oauth/token zid: uaa aud: testclient openid The exp time is 1753711964, that is seconds from Jan 1st, 1970, and corresponds to July 28, 2025
On Fri, Jul 31, 2015 at 12:57 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote: Filip,
Here's my client config:
useraccount
scope: clients.read oauth.approvals openid password.write tokens.read
tokens.write uaa.admin
resource_ids: none
authorized_grant_types: authorization_code client_credentials password
refresh_token
authorities: scim.read scim.userids uaa.admin uaa.resource
clients.read scim.write cloud_controller.write scim.me clients.secret
password.write clients.write openid cloud_controller.read oauth.approvals
access_token_validity: 315360000
autoapprove: true
Gotten from `uaac clients`
I really do not know what else I might be doing wrongly.
Does `test_Token_Expiry_Time()` also cover for client_credentials grant
type? I tried running the test with
`./gradlew test
-Dtest.single=org/cloudfoundry/identity/uaa/mock/token/TokenMvcMockTests`
and placed debuggers in order to view the generated expiration time.
Nothing was printed in the test results.
On Wed, Jul 29, 2015 at 6:11 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:
exp is expected to be 1753544877 when decoded. Unfortunately, this test fails, as exp reads 1438228276
most likely your client does not have the access token validity setup
correctly. See the test case I posted that validates my statements
https://github.com/cloudfoundry/uaa/commit/f0c8ba99cf37855fec54b74c07ce19613c51d7e9#diff-f7a9f1a69eec2ce4278914f342d8a160R883
On Wed, Jul 29, 2015 at 9:57 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:
Good. But my apologies. Assume:
creation time = 1438184877
access token validity (set by me) = 315360000
exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276
On Wed, Jul 29, 2015 at 5:43 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:
If I set the access_token_validity to 315569260, I'm expecting the token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?
It's a little bit different.
access_token_validity is how long the token is valid for from the time
of creation. thus we can derive
exp (expiration time) = token creation time + access token validity
you don't get to set the expiration time, since that doesn't make sense
as the clock keeps ticking forward.
in your case, having access token validity be 10 years, achieves
exactly what you want
Filip
On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:
Thanks again Filip.
However, here's what I mean,
If I set the access_token_validity to 315569260, I'm expecting the
token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?
line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)
Now the question is why do you have to do expirationTime*1000l since
the token when decoded originally set's this value to 1438209609
(without * 1000l)
Except I'm completely getting this all wrong?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Thank you. Needed to update to make this work.
uaac client update useraccount --access_token_validity 315360000
toggle quoted message
Show quoted text
On Fri, Jul 31, 2015 at 4:19 PM, Filip Hanik <fhanik(a)pivotal.io> wrote: Start a local server (./gradlew run --info)
In another console, the following commands
1. uaac target http://localhost:8080/uaa
2. uaac token client get admin -s adminsecret
3. uaac client add testclient --authorized_grant_types
client_credentials --access_token_validity 315360000 --authorities openid
-s testclientsecret
4. uaac token client get testclient -s testclientsecret
5. uaac token decode
The output from the last command is
jti: 7397c7c9-de08-4b33-bd6a-0d248fd983b1
sub: testclient
authorities: openid
scope: openid
client_id: testclient
cid: testclient
azp: testclient
grant_type: client_credentials
rev_sig: fbc56677
iat: 1438351964
exp: 1753711964
iss: http://localhost:8080/uaa/oauth/token
zid: uaa
aud: testclient openid
The exp time is 1753711964, that is seconds from Jan 1st, 1970, and
corresponds to July 28, 2025
On Fri, Jul 31, 2015 at 12:57 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:
Filip,
Here's my client config:
useraccount
scope: clients.read oauth.approvals openid password.write tokens.read
tokens.write uaa.admin
resource_ids: none
authorized_grant_types: authorization_code client_credentials
password refresh_token
authorities: scim.read scim.userids uaa.admin uaa.resource
clients.read scim.write cloud_controller.write scim.me clients.secret
password.write clients.write openid cloud_controller.read oauth.approvals
access_token_validity: 315360000
autoapprove: true
Gotten from `uaac clients`
I really do not know what else I might be doing wrongly.
Does `test_Token_Expiry_Time()` also cover for client_credentials grant
type? I tried running the test with
`./gradlew test
-Dtest.single=org/cloudfoundry/identity/uaa/mock/token/TokenMvcMockTests`
and placed debuggers in order to view the generated expiration time.
Nothing was printed in the test results.
On Wed, Jul 29, 2015 at 6:11 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:
exp is expected to be 1753544877 when decoded. Unfortunately, this test fails, as exp reads 1438228276
most likely your client does not have the access token validity setup
correctly. See the test case I posted that validates my statements
https://github.com/cloudfoundry/uaa/commit/f0c8ba99cf37855fec54b74c07ce19613c51d7e9#diff-f7a9f1a69eec2ce4278914f342d8a160R883
On Wed, Jul 29, 2015 at 9:57 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:
Good. But my apologies. Assume:
creation time = 1438184877
access token validity (set by me) = 315360000
exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276
On Wed, Jul 29, 2015 at 5:43 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:
If I set the access_token_validity to 315569260, I'm expecting the token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?
It's a little bit different.
access_token_validity is how long the token is valid for from the time
of creation. thus we can derive
exp (expiration time) = token creation time + access token validity
you don't get to set the expiration time, since that doesn't make
sense as the clock keeps ticking forward.
in your case, having access token validity be 10 years, achieves
exactly what you want
Filip
On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:
Thanks again Filip.
However, here's what I mean,
If I set the access_token_validity to 315569260, I'm expecting the
token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?
line 906 sets the value to 1438209609 when the token is decoded and
I believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)
Now the question is why do you have to do expirationTime*1000l since
the token when decoded originally set's this value to 1438209609
(without * 1000l)
Except I'm completely getting this all wrong?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
