Scripted rest api authorization header is encrypted

[Community Alums]

Hello, 
I have a scripted rest api that will be accessible using the oauth access token. I need the scripted rest api to call the record producer api and to do that i need to be able to supply the record producer api with an authorization header containing the bearer token which was supplied in the initial request of the scripted api. The problem im facing is that if i for example have the following in the authorization header "Bearer e_yCNLLsosA25Zi5E7IlNw8R0PQO9ASBC_7rKlVc_TQvaSVzQmTL8s4Bbxz2OFUjvv9m4vklvjqp-wd0IbtKMA" when i try to read it in the scripted rest api, i get a different value "$s$me7p9xHHyjP8IJve$Zf2NTE5eaLV6MKf6V0Tjb9RJoXUoAJyF/ayQX8a9lhs=" 

Why does this happen? and is there a way to decode this and get the real value of the token?

[Tony Chatfield1]

Hi, I would suspect the issue is that value is encrypted and so needs to be decrypted.
Hopefully this helps with syntax

Decrypting the value of the OAuth token received from third party OAuth provider. - Support and Trou...

[Community Alums]

I have already tried this, however, it does not output anything. I think token_received should contain the refresh token but unfortunately when generating the access token the api doesn't provide a refresh token.

[Tony Chatfield1]

Hi, unfortunately your question\issue is not clear from your posts.
What exactly is the 'Record producer API' and why does it need the bearer token if your data is already loaded to a Scripted Rest API endpoint? If the REST integration\authentication part of the process is complete, then I would expect any further functionality to be internal within the SNC instance; meaning the bearer token is not involved/does not need to be referenced\accessed.

Perhaps you could clarify your issue\process\intentions and share your code so that the community is in a better position to understand your configuration\problem.

[Euan Caldwell]

Hi Tony, I'm having the same issue as Mostafa, so perhaps I could explain what I'm doing.
I have a number of APIs which required OAuth Access Tokens for authentication. As part of this suite of APIs, I have one which is used to Rotate the password for the credential (related to the Access Token). To do this I need to identify the User which is related to the Bearer token.
They way this was achieved was as follows

1) Identifying the Application Registry using the client ID & Secret (provided via the payload). 

2) Query for active OAuth tokens against this application registry

3) Compare the token_received field for each token against the Bearer token provided in the Authorization  header

4) If they match, then get the user (from the user field)
In the Tokyo release, the bearer token in the Authorization header was received as plain text, so simple comparison. However, since upgrading to Vancouver the bearer token in the Authorization header has been encrypted in some manner and no longer matches the token supplied in the REST Call. Consequently my code can no longer Identify the OAuth Credential record, so cannot identify the calling user for which to rotate the password.
Does this make sense?