Skip to main content
Stack Apps

Return to Answer

added 36 characters in body
Source Link
Brock Adams
Brock Adams
  • 13k
  • 5
  • 39
  • 64

Yes, each time you invoke stackexchange.com/oauth/, you will get a fresh access token, even though old ones may still be valid.
For example:

  1. Go to /me/inboxLivedoc and hit Get Token twice, recording the token value each time (It will always be different).
  2. Then go to /access-tokens/{accessTokens}Livedoc and check each token. They will both still be valid! (Valid tokens return an entry in the items array. Invalid or expired tokens return nothing.)

At the very least, one would expect that issuing a new token for the same app+permissions+user should invalidate old tokens for that app+permissions+user. Littering the bitbucket with lots of unused, but valid, tokens just makes it easier for bad guys. ;)

Returning the last-issued token, if it is still valid, would be convenient, but there maymight be some reason not to.

You can submit a feature-request to changeimprove these behaviors but, unless a definite vulnerability is shown, it may be a while before anything changes. (API development seems to have stalled.)

Workaround-ish:

If you know who the user is by some other means (cookie, localStorage, etc.), and you stored her last valid access_token, you can use /access-tokens/{accessTokens} to see if that token is still valid.
If it is, just use that token and skip the fresh call to stackexchange.com/oauth/.

You need a way to track a user outside of access_token, but you should be doing that anyway.
Tokens are meant to be ephemeral and identification and authorization should be kept separate.

Also, protect yourself and the user and /access-tokens/{accessTokens}/invalidate tokens when you are done with them or if you are calling stackexchange.com/oauth/ for a fresh token.

Yes, each time you invoke stackexchange.com/oauth/, you will get a fresh access token, even though old ones may still be valid.
For example:

  1. Go to /me/inbox and hit Get Token twice, recording the token value each time (It will always be different).
  2. Then go to /access-tokens/{accessTokens} and check each token. They will both still be valid! (Valid tokens return an entry in the items array. Invalid or expired tokens return nothing.)

At the very least, one would expect that issuing a new token for the same app+permissions+user should invalidate old tokens for that app+permissions+user. Littering the bitbucket with lots of unused, but valid, tokens just makes it easier for bad guys. ;)

Returning the last-issued token, if it is still valid, would be convenient, but there may be some reason not to.

You can submit a feature-request to change these behaviors but, unless a definite vulnerability is shown, it may be a while before anything changes. (API development seems to have stalled.)

Workaround-ish:

If you know who the user is by some other means (cookie, localStorage, etc.), and you stored her last valid access_token, you can use /access-tokens/{accessTokens} to see if that token is still valid.
If it is, just use that token and skip the fresh call to stackexchange.com/oauth/.

You need a way to track a user outside of access_token, but you should be doing that anyway.
Tokens are meant to be ephemeral and identification and authorization should be kept separate.

Also, protect yourself and the user and /access-tokens/{accessTokens}/invalidate tokens when you are done with them or if you are calling stackexchange.com/oauth/ for a fresh token.

Yes, each time you invoke stackexchange.com/oauth/ you will get a fresh access token, even though old ones may still be valid.
For example:

  1. Go to /me/inboxLivedoc and hit Get Token twice, recording the token value each time (It will always be different).
  2. Then go to /access-tokens/{accessTokens}Livedoc and check each token. They will both still be valid! (Valid tokens return an entry in the items array. Invalid or expired tokens return nothing.)

At the very least, one would expect that issuing a new token for the same app+permissions+user should invalidate old tokens for that app+permissions+user. Littering the bitbucket with lots of unused, but valid, tokens just makes it easier for bad guys. ;)

Returning the last-issued token, if it is still valid, would be convenient but there might be some reason not to.

You can submit a feature-request to improve these behaviors but, unless a definite vulnerability is shown, it may be a while before anything changes. (API development seems to have stalled.)

Workaround-ish:

If you know who the user is by some other means (cookie, localStorage, etc.), and you stored her last valid access_token, you can use /access-tokens/{accessTokens} to see if that token is still valid.
If it is, just use that token and skip the fresh call to stackexchange.com/oauth/.

You need a way to track a user outside of access_token, but you should be doing that anyway.
Tokens are meant to be ephemeral and identification and authorization should be kept separate.

Also, protect yourself and the user and /access-tokens/{accessTokens}/invalidate tokens when you are done with them or if you are calling stackexchange.com/oauth/ for a fresh token.

added 73 characters in body
Source Link
Brock Adams
Brock Adams
  • 13k
  • 5
  • 39
  • 64

Yes, each time you invoke stackexchange.com/oauth/, you will get a fresh access token, even though old ones may still be valid.
For example:

  1. Go to /me/inbox and hit Get Token twice, recording the token value each time (It will always be different).
  2. Then go to /access-tokens/{accessTokens} and check each token. They will both still be valid! (Valid tokens return an entry in the items array. Invalid or expired tokens return nothing.)

At the very least, one would expect that issuing a new token for the same app+permissions+user should invalidate old tokens for that app+permissions+user. Littering the bitbucket with lots of unused, but valid, tokens just makes it easier for bad guys. ;)

Returning the last-issued token, if it is still valid, would be convenient, but there may be some reason not to.

You can submit a feature-request to change these behaviors but, unless a definite vulnerability is shown, it may be a while before anything changes. (API development seems to have stalled.)

Workaround-ish:

If you know who the user is by some other means (cookie, localStorage, etc.), and you stored her last valid access_token, you can use /access-tokens/{accessTokens} to see if that token is still valid.
If it is, just use that token and skip the fresh call to stackexchange.com/oauth/.

You need a way to track a user outside of access_token, but you should be doing that anyway.
Tokens are meant to be ephemeral and identification and authorization should be kept separateidentification and authorization should be kept separate.

Also, protect yourself and the user and /access-tokens/{accessTokens}/invalidate tokens when you are done with them or if you are calling stackexchange.com/oauth/ for a fresh token.

Yes, each time you invoke stackexchange.com/oauth/, you will get a fresh access token, even though old ones may still be valid.
For example:

  1. Go to /me/inbox and hit Get Token twice, recording the token value each time (It will always be different).
  2. Then go to /access-tokens/{accessTokens} and check each token. They will both still be valid! (Valid tokens return an entry in the items array. Invalid or expired tokens return nothing.)

At the very least, one would expect that issuing a new token for the same app+permissions+user should invalidate old tokens for that app+permissions+user. Littering the bitbucket with lots of unused, but valid, tokens just makes it easier for bad guys. ;)

Returning the last-issued token, if it is still valid, would be convenient, but there may be some reason not to.

You can submit a feature-request to change these behaviors but, unless a definite vulnerability is shown, it may be a while before anything changes. (API development seems to have stalled.)

Workaround-ish:

If you know who the user is by some other means (cookie, localStorage, etc.), and you stored her last valid access_token, you can use /access-tokens/{accessTokens} to see if that token is still valid.
If it is, just use that token and skip the fresh call to stackexchange.com/oauth/.

You need a way to track a user outside of access_token, but you should be doing that anyway.
Tokens are meant to be ephemeral and identification and authorization should be kept separate.

Also, protect yourself and the user and /access-tokens/{accessTokens}/invalidate tokens when you are done with them or if you are calling stackexchange.com/oauth/ for a fresh token.

Yes, each time you invoke stackexchange.com/oauth/, you will get a fresh access token, even though old ones may still be valid.
For example:

  1. Go to /me/inbox and hit Get Token twice, recording the token value each time (It will always be different).
  2. Then go to /access-tokens/{accessTokens} and check each token. They will both still be valid! (Valid tokens return an entry in the items array. Invalid or expired tokens return nothing.)

At the very least, one would expect that issuing a new token for the same app+permissions+user should invalidate old tokens for that app+permissions+user. Littering the bitbucket with lots of unused, but valid, tokens just makes it easier for bad guys. ;)

Returning the last-issued token, if it is still valid, would be convenient, but there may be some reason not to.

You can submit a feature-request to change these behaviors but, unless a definite vulnerability is shown, it may be a while before anything changes. (API development seems to have stalled.)

Workaround-ish:

If you know who the user is by some other means (cookie, localStorage, etc.), and you stored her last valid access_token, you can use /access-tokens/{accessTokens} to see if that token is still valid.
If it is, just use that token and skip the fresh call to stackexchange.com/oauth/.

You need a way to track a user outside of access_token, but you should be doing that anyway.
Tokens are meant to be ephemeral and identification and authorization should be kept separate.

Also, protect yourself and the user and /access-tokens/{accessTokens}/invalidate tokens when you are done with them or if you are calling stackexchange.com/oauth/ for a fresh token.

Source Link
Brock Adams
Brock Adams
  • 13k
  • 5
  • 39
  • 64

Yes, each time you invoke stackexchange.com/oauth/, you will get a fresh access token, even though old ones may still be valid.
For example:

  1. Go to /me/inbox and hit Get Token twice, recording the token value each time (It will always be different).
  2. Then go to /access-tokens/{accessTokens} and check each token. They will both still be valid! (Valid tokens return an entry in the items array. Invalid or expired tokens return nothing.)

At the very least, one would expect that issuing a new token for the same app+permissions+user should invalidate old tokens for that app+permissions+user. Littering the bitbucket with lots of unused, but valid, tokens just makes it easier for bad guys. ;)

Returning the last-issued token, if it is still valid, would be convenient, but there may be some reason not to.

You can submit a feature-request to change these behaviors but, unless a definite vulnerability is shown, it may be a while before anything changes. (API development seems to have stalled.)

Workaround-ish:

If you know who the user is by some other means (cookie, localStorage, etc.), and you stored her last valid access_token, you can use /access-tokens/{accessTokens} to see if that token is still valid.
If it is, just use that token and skip the fresh call to stackexchange.com/oauth/.

You need a way to track a user outside of access_token, but you should be doing that anyway.
Tokens are meant to be ephemeral and identification and authorization should be kept separate.

Also, protect yourself and the user and /access-tokens/{accessTokens}/invalidate tokens when you are done with them or if you are calling stackexchange.com/oauth/ for a fresh token.