nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Does a new bearer access token inviolate prior bearer tokens issued?

Lauren White

Hello, I have a question about the lifespan of bearer access tokens. If you were to call the token endpoint to refresh your access token, does the new bearer access token invalidate prior bearer access tokens issued? Example: two users are trying to checkout almost simultaneously, and before the checkout endpoint is called, for each user the code requests a new access token. Do subsequent requests invalidate prior access tokens? Thanks

Find more posts tagged with

Comments

Daniel Leonard

Hi Lauren,

In most cases the access token should be good until it expires. Two access tokens would not be dependent on each other.

When you request a new access token, the old refresh token will no longer be valid, unless you are using the “preserve refresh token” option

Lauren White

Hi Daniel, thank you for your response. We are working on a solution that uses the Blackbaud checkout form and the payments api. We only want to authorize Blackbaud to access the SKY api one time and then have it reconnect indefinitely, or at least for a year. (We don't want users of the site to have to create a Blackbaud account, select authorize etc during their checkout experience).

Is this code flow what Blackbaud recommends in this case?

1. Pass authorized payment token from Blackbaud checkout form to our backend

2. Use the stored refresh token that has been previously requested with the preserve parameter set to true to call the token endpoint to request a new access token

3. Use the returned access token to call the checkout transaction endpoint and finalize the payment

*We would use the stored refresh token to repeatedly generate new access tokens for each transaction. On each call to the token endpoint, the preserve parameter would be set to true to prevent invalidating the stored refresh token.

Is this how Blackbaud recommends implementing these applications?

Lauren White

Ah ok - that sounds good. Thank you, Daniel!

Could we re-visit my code flow question from my prior response? It sounds like the proposed code flow solution would work fine. Is this the way Blackbaud generally sees customers using their products together?

Daniel Leonard

Hi Lauren,

Your overall soluition seems valid to me. I would suggest not using preserve refresh token. If the preserved refresh token were compromised it could be used for up to a year to get an access token. Also, you will need to remember a year from its first use to get another authorization code and refresh token.