I try to authenticate Slack. I will use, oauth, if I can.
How can I get the code field which is required for oauth.access?
https://api.slack.com/methods/oauth.access
To be able to test the method, I should fill;
client_id Required
client_secret Required
code Required
redirect_uri Optional
Alright I get client_id and client_secret from OAuth Information. But where should I get the code field?
The steps of negotiating tokens with OAuth are sequential -- it's not possible to test all of the OAuth API methods in the tester alone, as part of the sequence of events is your server receiving a callback containing that token value you'll need for the oauth.access step.
The OAuth documentation lays out the steps in order and is probably a better overall reference than the method documentation alone.
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.
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.
I am trying to do a request my Netsuite RESTlet using Alamofire (SWIFT) but I meet several difficulties:
In the documentation it's specify the different parameters needed (see below).
DOCUMENTATION:
An OAuth 1.0 RESTlet authorization header requires the data described in the following table. Some of these values can be obtained from the NetSuite UI. Other values must be calculated. Typically, your integration should include logic to identify these values and generate the finished header. Follow the OAuth 1.0 protocol to create the authorization header.
However in postman I am using extra parameters (consumer Secret and the Token Secret) and it's works if I remove them it doesn't works
To finish when i check the Authorization header generated by postman, I see only the specify parameters in the documentation :
OAuth realm="my realm",oauth_consumer_key="myConsumerKey",oauth_token="myAccessToken",
oauth_signature_method="HMAC-SHA1",oauth_timestamp="1543488570",
oauth_nonce="ERxdLbUfkeh",oauth_version="1.0",oauth_signature="UeqmxAyeUqtPoICLo%2FARsQE8B1E%3D"
If someone can explain me this, I could implement TBA authentification in my Application but for now I need to understand better this authentification.
I also spend a few hours trying to make it work. In my case I wasn't adding the account ID to the realm param. Here a picture of what I ended with:
Here where you can get the account ID:
I hope it helps
The explanation of why the consumer secret and the token secret are needed by Postman to generate the token is shown in SuiteAnswer 42019 - as referenced in the Notes section beside oauth_signature in your screenshot above. From that page:
Sign the result string from step 5 using the consumer secret and token secret concatenated using '&' (For this case, HMAC-SHA1 or HMAC-256).
In other words, Postman uses the secrets to generate the output which authenticates your credentials - you cannot generate the oauth_signature correctly without them.
I ran into a lot of issues with NetSuite broken RESTlet/TBA connections as well. I did build this out in our software to help out customers. You can see the methods I used in the article below.
Using NetSuite TBA by Calling a RESTlet from an HTTP Source or Target
When using OAuth in the Google Cloud Endpoints JavaScript client, how do you preserve the secrecy of the client ID?
How to implement 0Auth in the Google Cloud Endpoints JavaScript client is detailed here. In the code snippet below the client ID is passed as a parameter to the OAuth method.
gapi.auth.authorize({client_id: CLIENT_ID, scope: SCOPES,
immediate: mode}, callback);
Since the end user will receive the script file in clear text, regardless of the use of HTTPS, how would you avoid handing the client ID over to every user you serve? After all, it would be rather simple to comb the JavaScript code to find the client ID.
You don't. Anyone can see and intercept it (as you stated), which is the root of the confused deputy problem.
That's why you validate your tokens. For a simple explanation of token validation and the confused deputy problem, check out this great SO question and answer on How and why is Google OAuth token validation performed.
I'm implementing a strategy to connect to an OAuth provider implemented using oauth-plugin. In the "request_phase" function, I wrote:
def request_phase
options[:response_type] = 'token
super
end
But in the HTTP request sent, it has "...&response_type=code"
I followed other examples to set response_type in request_phase as demonstrated for example with SalesForce strategy:
https://github.com/quintonwall/omniauth-rails3-forcedotcom/wiki/Build-Mobile-Apps-in-the-Cloud-with-Omniauth,-Httparty-and-Force.com
Please advise on how to change the response_type.
Thanks
Rami
As specified by the OAuth 2.0 documentation, "code" is the only valid value for the authorization code flow:
response_type
REQUIRED. Value MUST be set to "code".
You will then have to use the auth_code to make a second request for a token. It's possible the provider you're using only supports this method.
The flow that uses token as a response type is the implicit grant flow, which has rather different use cases and may not be supported by the provider you're trying to work with.