Moving to OAuth 2.0 in valence and having some questions about Token, refresh Tokens etc...

Samson.C.778
Samson.C.778 مشاركات : 11 🌱
تم تعديل 2025/08/13 في Social Groups

Hi all,

I've finally decided to start looking to move the Valence authentication module I started on my side back in 2012 to oAuth 2.0…

I have a few questions while looking at the redesign of the internal library… and it is about the authentication, the life of the Token and refresh Tokens.

When I authenticate to

https://auth.brightspace.com/oauth2/auth

My understanding is that the system will provide me with a token and a refresh token.

The Refresh token can be used to renew the token at
https://auth.brightspace.com/core/connect/token

This link will also provide a new token for me to continue using and refresh in the future, should I need to.

I want to know more about what happens to the token when a refresh token or token should another authentication takes place.

ie, I have

program 1, using oAuth with clientID 1 to get a token, it is processing its tasks (takes about 4 hours), it refreshes its token while it is running during that 4 hour period…

program 2, using oAuth with clientID 1 to get another token, it is processing something else that takes 30 mins.. will also handle its own token refreshes.

Will the program that is run first be nullified by the program that is run second? Or will the system fully acknowledge the two authentication?

From what I've experienced via Postman so far, getting the initial token seems to require user authentication. Is there a way to bypass this?

If not, let's say a token expires. Can it still be refreshed?

Thanks in Advance,
Sc.

الكلمات الدلالية:

التعليقات

  • Mohit.B.878
    Mohit.B.878 مشاركات : 79 🤝🏼

    Hello @Samson.C.778

    My name is Mohit, and I am a member of the Product Support team. Thank you for your question and for reaching out via the Community channels. I am currently checking with our internal team on the queries you have raised, and I will aim to provide a full response by tomorrow.

    Thank you for your patience.

    Best Regards,
    Mohit Bhargav

  • Mohit.B.878
    Mohit.B.878 مشاركات : 79 🤝🏼

    Hello

    I have received a response from our Valence Team regarding your queries. Please see the summary of their responses below:

    Is there any way to bypass [the required user authentication to gain an access token]?

    Currently, no. All third-party applications using Brightspace APIs with OAuth2 auth must use the three-legged authorization code grant workflow to gain an access token. Whenever the app wants to make an API call, it must use an access token that identifies the known and willing Brightspace user on whose behalf it makes the call. This requires that, when the app requests an access token, it involves an active user session to grant this access. In the future, we are planning on delivering a new feature that will allow third-party apps to use the two-legged 

    Client Credentials Grant workflow to get an access token: this will not require a user with a session to be involved in the token request flow, but it will  require other factors (the API calls are still bound to a known user, and in this case, the app using this two-legged flow must have an up-front identified and bound “service user” defined in Brightspace that will act as the user context for all its API calls)

    [If an access token] expires, can it still be refreshed?

    Yes. This is intentional and part of the OAuth2 standard. Access tokens are short lived (measured in minutes). While the access token is alive, you can use it to make API calls. When the access token expires, you can no longer make API calls with against a Brightspace. However, you can still engage in the refresh token workflow: you can go back to the auth server, hand in your one-use refresh token, and get back a new access token and a new (one-use) refresh token. Refresh tokens are long-lived (lifespan measured in small number of weeks). In general, this gives nearly all app use-cases sufficient time to just keep their access for the user identified on an access token alive by continually refreshing it. As long as you engage in the refresh workflow before the refresh token expires, you can turn it in for a new access token (same privileges as the old one) and one-use refresh token.

    What if I have two apps with the same Client ID?

    We counsel strongly against this. Distinct applications should not share a Client ID. Each app integration should be separately registered, and have its own Client ID.

    (Apart from anything else, for general security reasons and ability to audit the behaviour of OAuth2 clients, it’s good not to be ambiguous about which integration is performing which access with which token…)

    Still, what if I have two instances of the same app (same Client ID) running, each managing their own tokens for access? Will the lifecycle of their access tokens collide with one another?

    This last question is a bit more complicated, but I think still has a straight-forward answer. This is what I believe to be correct based on how I think the system works… I may be wrong here, but I don’t think so.)

    Since access tokens are bound to scopes requested by the app at the point of requesting the token, and since tokens are also bound to users, it is of course entirely possible for a Client ID to have multiple access tokens at once. When issuing an access token, the authorization server will remember the access token details in combination with the refresh token issued for that access token — this ensures that when the app refreshes the access token, they will get back an access token with the same details.

    Therefore, it’s entirely possible for an application to maintain two separate streams using two access-token/refresh-token pairs, with exactly the same details. Each stream has its own governing tokens and must manage the lifespans of them to keep the tokens alive; the fact that the tokens grant the same access for the same user is probably wasteful, but not really material

    Please let us know if this addresses all your queries, or if you have any additional questions or require further information

    Best Regards,
    Mohit Bhargav

  • Samson.C.778
    Samson.C.778 مشاركات : 11 🌱

    Thanks @Mohit.B.878,

    It is sad to hear this… as I'll need to do a token maintainer, it seems… I have another question in relations to this.

    Let's say a token have a lifespan of 3 hours, it is renewed with 1 hour remaining. Will the original token still be usable until it expires or will it be like the token refresh token, expired upon renewal?

    As for the Client ID separation, I'd have to think very carefully about this, as it may result in over several dozens of oAuth on our side… 🤔
    It just feels weird with the following:
    Client ID 1: Scope core
    Client ID 2: Scope datahub
    Client ID 3: Scope Core and DataHub

    I could easily use Client ID 3 to do the jobs for 1 and 2, or a combination of 1 and 2 to do 3… but I'd have to think about it more… 🤔