# Refresh token exchanges to /oauth2/default/v1/token 401s from staging but not from local **URL:** \ **Category:** API\ **Tags:** spring, oauth, java\ **Created:** [November 28, 2022, 7:22pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587 "2022-11-28T19:22:55Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![slemly](https://avatars.discourse-cdn.com/v4/letter/s/ee59a6/32.png) [@slemly](https://devforum.okta.com/u/slemly)\ **Post date:** [November 28, 2022, 7:22pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587/1 "2022-11-28T19:22:55Z")
We recently built out an endpoint in our API to allow a user to supply a refresh token and retrieve a new refresh token, using a request from our services as [described here](https://developer.okta.com/docs/guides/refresh-tokens/main/#use-a-refresh-token). When testing on our local machines, this flow was able to be successfully executed (a user could supply an expired bearer token + their refresh token and was issued a new bearer + refresh token), but when we deployed endpoint to our staging environment, our call from our services to the Okta `/oauth2/default/v1/token` endpoint was given a 401 response. Token rotation is enabled, and the ~~scope~~ grant type we are requesting in the request params is `refresh_token` . The scopes we are requesting are `offline_access` and `openid`. What would be a potential reason behind this? Is the request detailed in the linked article not intended to be made to the Okta API from a backend service, and rather made by our user? ---
**Author:** ![warren](https://avatars.discourse-cdn.com/v4/letter/w/97f17d/32.png) [@warren](https://devforum.okta.com/u/warren)\ **Post date:** [November 29, 2022, 5:02pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587/2 "2022-11-29T17:02:11Z")
The scope should be `offline_access` for getting a refresh token instead of `refresh_token`. ---
**Author:** ![slemly](https://avatars.discourse-cdn.com/v4/letter/s/ee59a6/32.png) [@slemly](https://devforum.okta.com/u/slemly)\ **Post date:** [November 29, 2022, 6:21pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587/3 "2022-11-29T18:21:12Z")
`refresh_token` was referring to `grant_type`; my mistake. The scopes are `offline_access` and `openid`. ---
**Author:** ![warren](https://avatars.discourse-cdn.com/v4/letter/w/97f17d/32.png) [@warren](https://devforum.okta.com/u/warren)\ **Post date:** [November 29, 2022, 7:11pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587/4 "2022-11-29T19:11:02Z")
The 401 response could mean the wrong client credentials were provided. Can you check if the value you’re using for the authorization header is valid? ```auto authorization:'Basic MG9hYmg3M...' ``` ---
**Author:** ![slemly](https://avatars.discourse-cdn.com/v4/letter/s/ee59a6/32.png) [@slemly](https://devforum.okta.com/u/slemly)\ **Post date:** [November 29, 2022, 7:32pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587/5 "2022-11-29T19:32:47Z")
When running this locally, the request completes successfully without an `Authorization` header, but not the case on our staging environment. I am assuming an expired authorization token cannot be passed as the `Authorization` header. We will add this and attempt it on our staging environment and see if it makes a difference. Our use case is that a user on a mobile app has had their authorization token expire, and is attempting to use their refresh token to acquire a new one via our endpoint to avoid going through a login flow. If what we’re attempting isn’t the proper way to go about this, I would be more than open to alternatives! ---
**Author:** ![warren](https://avatars.discourse-cdn.com/v4/letter/w/97f17d/32.png) [@warren](https://devforum.okta.com/u/warren)\ **Post date:** [November 29, 2022, 9:30pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587/6 "2022-11-29T21:30:04Z")
The Authorization header containing the client credentials should be required. Could the local test app be appending it automatically? The use case makes sense to me. If the access token or id token expires, you can use the refresh token to retrieve a new set of tokens. ---
**Author:** ![slemly](https://avatars.discourse-cdn.com/v4/letter/s/ee59a6/32.png) [@slemly](https://devforum.okta.com/u/slemly)\ **Post date:** [November 29, 2022, 9:47pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587/7 "2022-11-29T21:47:44Z")
Just tried using the user’s bearer token to make that request in the `Authorization` header and got a 401 back from Okta when doing so; this was done on our local instance. I don’t believe the local application would be appending the request automatically - the code of our request is below: ```auto NewTokenResponse response = webClientBuilder .baseUrl("https://.okta.com/oauth2/default/v1/token") .defaultHeader(HttpHeaders.CONTENT_TYPE, APPLICATION_FORM) .build() .post() .uri(uriBuilder -> uriBuilder .queryParam("grant_type", GRANT_TYPE_VALUE) // grant type is "refresh_token" .queryParam("refresh_token", refreshToken) .queryParam("scope", SCOPE_VALUE) // scopes are "offline_access openid" .queryParam("client_id", clientId) .build()) .retrieve() .bodyToMono(NewTokenResponse.class) .block(); ``` How would one go about checking if the local version of the application is inserting a header of some kind? ---
**Author:** ![slemly](https://avatars.discourse-cdn.com/v4/letter/s/ee59a6/32.png) [@slemly](https://devforum.okta.com/u/slemly)\ **Post date:** [November 29, 2022, 9:58pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587/8 "2022-11-29T21:58:45Z")
As we’re using a mobile/native application, we followed instructions [detailed here](https://developer.okta.com/docs/guides/oie-embedded-common-refresh-tokens/nodeexpress/main/#native-and-spa-applications) that state we can make the request without an authorization header. ---
**Author:** ![slemly](https://avatars.discourse-cdn.com/v4/letter/s/ee59a6/32.png) [@slemly](https://devforum.okta.com/u/slemly)\ **Post date:** [December 1, 2022, 8:12pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587/9 "2022-12-01T20:12:11Z")
We got our problem solved - turns out the clientId in the yml for our staging environment didn’t match the one we were using on our local environment. The clientId on local was for a native app, and the clientId on our staging was for a Web app. For posterity: we found the [oidc docs](https://developer.okta.com/docs/reference/api/oidc/#token) to be very helpful; they offered more details about what parameters are needed in which requests (hence why ours were working without a redirect uri nor authorization header) ---
**Author:** ![system](https://global.discourse-cdn.com/oktadev/original/1X/589c4c5f80de422d01f47cee7185a7fb8227835c.png) [@system](https://devforum.okta.com/u/system)\ **Post date:** [December 2, 2022, 8:12pm UTC](https://devforum.okta.com/t/refresh-token-exchanges-to-oauth2-default-v1-token-401s-from-staging-but-not-from-local/22587/10 "2022-12-02T20:12:23Z")
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.