Legacy API Tokens

the docid\ hbyhyv8svq0u6bzhuv50 describes our current authentication workflow this page describes our legacy method, which is no longer recommended the bsn cloud authorization server supports the following token timespans we reserve the right to change these timespans at any time access tokens have a timespan of 5 minutes 30 seconds refresh tokens have a timespan of 12 hours sessions have a timespan of 24 hours refresh token based authentication workflow to access the bsn cloud apis you are required to submit your credentials in order to obtain your access and refresh tokens access tokens are temporary credentials that grant access to a protected resource, while refresh tokens are used to obtain new access tokens when the current ones expire when your application or script accesses the token endpoint and authorizes successfully, it is granted an access token and a refresh token the access token is then passed with each api request to allow the resource to be accessed bsn cloud token endpoint https //api bsn cloud/2022/06/rest/token/ after a period of time (the access token lifetime), making the api call will fail with an error because the access token has expired at this point, your code should use the refresh token to exchange for a new access token this is done by passing the refresh token to the token endpoint, which verifies the refresh token and issues new access and refresh tokens in the response you should then use this new access token in your subsequent api call this process continues until either the refresh token is expired the refresh token is revoked the current session is expired at this point you will need to re authenticate with your credentials the following flow diagram shows this flow screenshot 2024 08 02 at 8 55 33 am png the client application authenticates with the bsn cloud token endpoint by providing the credentials if the credentials are valid, an access token and a refresh token are returned in the result the client application makes an api call and must pass the access token the api component validates the access token and allows access to the resource steps 3 and 4 can continue until the access token expires and the api signals this by returning an error response (this will be a 401 or 403 status code) when the access token expires, the client application requests a new access token by providing the refresh token the bsn cloud token endpoint then issues a new access token and a new refresh token steps 3 through 7 repeat until the refresh token expires, or is revoked, or the current session ends the client needs to re authenticate with the authentication server once again and the flow repeats from step 1 see the following bsn cloud api authentication documentation for more info docid 0qhibo6ras8zwyjybeh0r docid 0qhibo6ras8zwyjybeh0r docid 0qhibo6ras8zwyjybeh0r docid 0qhibo6ras8zwyjybeh0r refresh tokens so, why do we need both access tokens and refresh tokens? why don’t we just set a long expiration date, like a month or a year for the access tokens? if we do that and someone manages to get hold of our access token they can use it for a long period, even if we change our password the idea of refresh tokens is that we can make the access token short lived so that, even if it is compromised, the attacker gets access only for a short period with refresh token based flow, the authentication server issues a one time use refresh token along with the access token your application should store the refresh token safely every time your application sends a request to the server it sends the access token in the authorization header and the server can identify the application using it when the access token expires, the server will send a token expired response when your application receives the token expired response, it must send the refresh token to obtain a new access token and refresh token if something goes wrong, the refresh token can be revoked which means that when the your application tries to use it to get a new access token, that request will be rejected and you will have to enter the credentials once again and authenticate why can’t we just use steps 1, 2 and 3 constantly instead of having to deal with refresh tokens? issuing many active access tokens is not an efficient process and it leads to an increase in storage and decrease in performance for our backend servers up until now we have permitted this approach but going forward we will be adding limitations to the number of unexpired access tokens that an application can have at any one time