Has anyone had to deal with 2 OAuth 2.0 tokens in postman? I am in the process of automating some API calls for testing and have been stuck at a point where I had to make 2 Authorization requests to get a successful response. I have one authorization token at the collection level and other at the request level. However every time I generate a token at the collection level and then when I generate the second token the first one is being overridden? Is there a workaround? I have tried collection variables and variables and all of them seem to be overridden on the second OAuth call.
The gist of the story is you cannot use 2 bearer tokens in a single request. It is not practically possible. Do you use 2 passwords to open your account? No, right. Same is the case with bearer token. Maybe if you tell what you need to achieve using both the tokens someone might be able to help.
Related
I'm using OpenID Connect to control access to my REST API. One of the things I need to do when servicing a request is get the OIDC UserInfo based on the access token in request's Authorization: Bearer ... header.
To this point I've been working with JWTs and this works fine. I'm looking at expanding this to work with opaque tokens as well.
My strategy has been based on my understanding of the OpenID Connect Discovery spec, section 4:
Extract the iss from the access token.
Discover the userinfo endpoint by getting ${iss}/.well-known/openid-configuration and querying the JSON for userinfo_endpoint.
HTTP GET the userinfo_endpoint, passing the access token as an Authorization: Bearer ... header.
This works fine for opaque tokens... except for step 1. Currently, I have to know who the issuer is via an out-of-band mechanism because I don't know how to get the issuer from the opaque token (which, to be honest, makes sense given that it's opaque). I see a few possibilities:
Maybe I'm just supposed to know who issued it and my question is misguided.
Maybe the best thing to do is try a list of known issuers and see if one of them works.
Maybe there's a mechanism for discovering the issuer of the opaque token. (The spec refers to WebFinger, but that doesn't seem like it fits my use case.)
Maybe there's something I haven't considered...
Thanks all for any help.
The standard mechanism for dealing with opaque tokens is via introspection. Also the preferred option is for there to only be a single type of access token - issued by your Authorization Server (AS), which sits alongside your APIs.
The introspection result can be a claims payload or a JWT. It is common to plug in an API gateway, as in this article, so that the gateway makes the actual introspection call. The gateway should then cache results for subsequent calls made with the same access token.
An opaque token is typically a GUID or something similar, and the issuer value is not stored in the token - it is instead stored in the issuing Authorization Server's back end state. The only way to determine the issuer is to try to introspect the token.
FOREIGN ACCESS TOKENS
Aim to avoid using foreign access tokens in your APIs as in the following examples. This can make it difficult to control data added to tokens and token lifetimes:
User signs in with Google - then API uses Google access tokens
User signs in with Microsoft - then API uses Microsoft access tokens
It is preferred instead to use 'federated login capabilities' of your Authorization Server, leading to the following cleaner result, and fewer issues:
User signs in with Google - then API uses your AS access tokens
User signs in with Microsoft - then API uses your AS access tokens
Answering my own question:
You cannot discover anything from an opaque token alone.
An opaque token could be anything, even just a UUID that serves as a key to a database table in the Authorization Server. The only way anything can be obtained with such a token is by calling the introspection endpoint.
(Even if there is anything encoded in the opaque token, the only way it should be decoded is by calling the introspection endpoint.)
To that extent, my original question was somewhat misguided in that I was attempting to decode something that doesn't intrinsically express its encoding. It's rather like trying to use a pointer without knowing what it points to. Indeed, I've found a number of places where the term "reference token" is used to mean "opaque token."
Thanks to Gary Archer for some helpful feedback.
I have 2 internal Rails services, which need to speak to each other.
I need an advice how to make it secure enough and with minimum effort.
Currently service A sends Authorization HTTP header to service B, which contains secret token. Simple HTTP Token-based method, nothing special. But I also need somehow to communicate a user token, so service B will know, which user is talking to it.
My current solution is following:
send Authorization Token token=blabla user_token=blabla2
use existing in Rails methods to parse it
identify user by provided user_token
inspired by this StackOverflow post
Alternatives:
Amazon way with something like: Authorization: MY-APP-V1 Token=blabla Credential=user_token, but I need custom parser for it.
Custom HTTP header like X-USER-TOKEN, but seems like RFC is not in favor of this idea.
Your proposal or suggestion
Thank you very much for any help.
I'm curious as to why the user token is not enough, can you elaborate on this?
But assuming you want to continue with the double-token approach, something like JWT could be used to encode the user token with the secret token. That way you will just have 1 token and can send it simply as Authorization: Bearer xxxxxx.
When I do the initial authentication to the Asana API with OAuth, it gives me a refresh_token as well as an expires_in of 3600 ms (1 hour).
What is the typical way of determining whether my app will need to use the refresh_token to get a new access_token?
I can think of two options:
Watch for an authentication error and then request a new access_token.
Store the date/time from now until 1 hour from now. Then with each API request, check the date/time to see if that time has already passed, and if so, request a new access_token.
Is there a better way than one of these two options? I don't see a recommendation from Asana in their OAuth documentation.
Thanks!
(I work at Asana.)
Great question! Both of your ideas are quite reasonable and should work - pick whichever is easiest / makes sense for your implementation. #1 is a little more robust in case there is skew with the timing, but if you just add some padding (be sure to request the token 1-2 minutes before expiration) then #2 should work just fine.
Note that it is always possible for the user to revoke the token, in which case when you go to get a new token the request will fail.
This seems like a good thing for us to recommend in the documentation, and possibly even add an automatic mechanism for in our client libraries.
I'm trying to find the simplest way of implementing token based authentication for a number of ASP.NET MVC actions.
The Api controllers sit alongside a web app, so I need to be able to specify which actions/controllers are subject to Api authentication.
I already have a membership provider that is used for forms authentication so I'd like to reuse this to validate the user and build the returned token.
I've read several articles on implementing OAuth, but most seem really complex. I've seen several examples of using an API key, but I want to request a token and then pass it back as a parameter not necessarily as a value in the HTTP header.
Essentially process needs to be:
User requests token from auth action passing in username and
password.
Service returns enc token
User passes enc token to future calls as a parameter to auth
What's the typical way this is done, does the client (say ajax call) need to compute a hash of the user name/pass in 1)? or plain text ok over TLS/SSL?
Any advice appreciated.
What are you concerned about with what you described?
The process you described seems viable. Typically systems will have an expiration on how long the token will be valid for, after which they need to get a new token. There are many variations for expiration though (fixed time, sliding time, etc..).
To your question regarding the username / password, the client shouldn't hash them. Just make sure they are transmitted via a secure method (SSL).
I am looking at using Savon to consume a SOAP API. One of the requirements of this particular API is that an authentication token be supplied in each request to the API. That is, apart from the request that returns the authentication token itself. That call just needs a username and password. The token expires after 20mins of inactivity.
My question is, what is the best practice for storing this token? It's surely not advisable to make two requests every time, one for the token and one for the actual request?
I was considering storing it in a session variable but this would mean generating a new token for each visitor, which I presume is not necessary. However, it would mean I could set a 20 minute expiry on it very easily though.
If I store it in the database, how would I know whether or not it will have expired before making the call to the API, without a lot of extra logic?
Or, should I store it in the database and simply make a background call to the API every few minutes to ensure the token never expires?
Or am I barking up completely the wrong tree?!
Thanks for any advice.