When I try to make the following call using postman I get no response: https://slack.com/oauth/authorize?client_id={{client id}}&scope=chat:write:bot
However, when I try it without the scope I do get a response, saying I need to add a scope.
I've put this call together according to the first step of https://api.slack.com/docs/oauth
I've tried using both GET and POST verbs and my header is empty.
What can I do to get a authorization token for Slack?
This is part of the OAuth flow/spec.
What you need to do to is follow/perform the OAuth flow:
Register your application with slack
Provide a redirect_uri - this is the callback URI - this callback/handler will be called with the authenticationCode by the slack OAuth server.
Only if the user authorizes your app, Slack will redirect back to your specified redirect_uri with a temporary code in a code GET parameter, as well as a state parameter if you provided one in the previous step.
It's true that the redirect url is optional, but if left out, Slack will redirect users to the callback URL configured in your app's settings.
the authenticationCode then needs to be changed in code to the accessToken.
So if all is well and user gave its consent, you need to exchange the authorization code for an access token using the OAuth.access API method (method documentation), int the following URL and retrieve your accessToken.
https://slack.com/api/oauth.access
if you decide to use a bot user and your Slack app includes a bot user, you will get an additional node containing an access token to be specifically used for your bot user.
Related
So I've been trying to use Djoser JWT and I don't know how to login in it. As far as I know you create a request with your login credentials to this url /jwt/create/ and get the access and refresh token and maybe get the user object from /users/me/. This is where I got stuck, where do I go from here?
You correctly understood the first step of the process. Basically, you can now:
Add the access token in the header of your next requests.
This will transparently authenticate the user thanks to the Simple JWT plugin and you will be able to access him with the usual request.user in the views.
Refresh the access token each time you get a 401 response.
The access token is supposed to be short-living for security concerns and a 401 response from the server indicates that the one your are using is expired. So you have to get a new one by sending the refresh token to the token/refresh/ API and, then, make your request again.
You can read this article if you need more detailed explanations about this process or JWT.
When using Postman to fetch an access token via Authorization Code, one of the fields I need to enter is for the Callback URL, aka the redirect URI query param when it's making the request to the authorization endpoint. I understand this URL needs to be registered/whitelisted within the OAuth provider, but my question is how does postman actually handle/intercept that request/redirect back when it's localhost-based? For example, if I already had a local server running on http://locahost:8090, and I told postman to use http://localhost:8090 for that callback, how does Postman end up seeing that request/redirect back (to exchange the auth code for an access token) instead of my local web server handling that request?
TL;DR: Postman basically ignores the callback URL when processing the response.
The Long Story
It does need it, but only for the request. As you say, it needs to be correct - exactly matching the IdP client application config - but that's it.
Postman is just helping you acquire the token, it doesn't need to provide it to the consuming application, which is the whole point of the redirect URL - a static path known by the client app and the OAuth client application that makes sure an evil website / intermediary doesn't steal tokens by abusing the redirection flows.
Since it's not meant to work on a browser on the internet, Postman can ignore the redirect. Once the IdP responds with the token then, as far as Postman is concerned, it's good to go. It can save the token in the local token store and use it to make API requests.
Implicit Flow
This is set up to get a token from an Okta endpoint:
When I click "Request token", Postman makes a request like this:
GET https://exampleendpoint.okta.com/oauth2/default/v1/authorize?nonce=heythere&response_type=token&state=state&client_id={the_client_id}&scope=profile%20openid&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fimplicit%2Fcallback
Postman pops a browser to make this request to the /authorize endpoint, at which the IdP then either creates the token (if the browser already has a cookie), or performs various redirects to authenticate the user and then create the token.
At the end of this flow, Postman will receive the 302 from the IdP that contains the token (on the location header). The target of that redirect is the redirect URL configured in the IdP:
302
Location: http://localhost:8080/implicit/callback#access_token=eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.{the_rest_of_the_token}&token_type=Bearer&expires_in=3600&scope=profile+openid&state=state
At this point Postman grabs the token from the #access_token parameter and it's good to go.
Auth Code Flow
Auth Code flow comes in 2 flavours:
Auth Code (Classic)
Auth Code + PKCE
Auth Code flow has been seen as "better" than the implicit flow because it requires a 2nd step in the process to get an access token. You hit authorize which gives the client a code and the code is then exchanged for the tokens. This code for token gives more chances for the server side components to do more stuff - extra checks, enrich tokens and various other things.
Q: Why are there 2 Auth Code flows?
A: The problem with this was that it required a server side component, which many SPA's and/or mobile apps didn't want to host. The endpoint that receives the code and gets the token(s) had to maintain credentials - a client id and client secret - which are required by the IdP when creating the token. PKCE is an extension that removes the requirement for a trusted server. It's adds computed hash to the /authorize call, which the IdP remembers, and then on the subsequent call to /token the client provides the source value of the hash. The server does the same computation, checks it's the same as that on the original request and is then satisfied that it's not handing out tokens to a bad guy.
Auth Code with PKCE
In terms of redirects, this is exactly the same as implicit. But for requests, it needs to make the second request to exchange the code for the tokens. The main differences here are
the access token URL, which is where to send the code and get tokens in response.
the code challenge and verifier, which are PKCE requirements for generating and computing the hash
The requests are now as follows:
The GET to /authorize
GET https://exampleendpoint.okta.com/oauth2/default/v1/authorize?nonce=heythere&response_type=code&state=state&client_id={client_id}&scope=profile%20openid&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fimplicit%2Fcallback&code_challenge=E7YtiHqJRuALiNL_Oc5MAtk5cesNh_mFkyaOge86KXg&code_challenge_method=S256
Postman will pop the browser (and the IdP will redirect it through login if required)
The eventual code response is also 302, however the location header contains the code rather than tokens:
location: http://localhost:8080/implicit/callback?code=J3RlQqW122Bnnfm6W7uK&state=state
So now the client needs to call the endpoint defined in the "Access Token URL" field to get tokens:
POST https://exampleendpoint.okta.com/oauth2/default/v1/token
Body:
grant_type: "authorization_code"
code: "J3RlQqW122Bnnfm6W7uK"
redirect_uri: "http://localhost:8080/implicit/callback"
code_verifier: "Fqu4tQwH6bBh_oLKE2zr0ijArUT1pfm1YwmKpg_MYqc"
client_id: "{client_id}"
client_secret: ""
And the response is a good old 200 that doesn't redirect - the authorize call sends the client back to the final redirect landing page, and the POST is just a normal request with the tokens on the the response
{"token_type":"Bearer","expires_in":3600,"access_token":"eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.*******","scope":"profile openid","id_token":"eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.********"}
I'm trying to make a request from my reactjs app existing on "localhost:3000" to my django living in "localhost:8000"
I was expecting some authentication token in header to passed along with the request, but it's not the case. The request seems to be stripped and the token is nowhere to be found. Unless I pass the token in the url as a parameter (which exposes the token that can be decoded. I don't like it), I can't seem to be able to get the token in any way.
so my questions:
is this CORS issue? My understanding is that CORS usually deals with javascripts only, and Django already has the middleware to deal with this.
I'm currently using a GET as method. Does using a POST help in this case? How would the reactjs script be written? Currently it's just a href attached to a NavItem
and ultimately:
How do I pass the token from reactjs to django?
We can perform the implicit grant on the front-end and then configure the Django API in Auth0 and specify its identifier in the audience parameter. This would grant you an access token which you could then use against your API. Your API would then verify the token and check the audience is correct. (This has a good overview of the process https://auth0.com/docs/api-auth/grant/implicit and then with the API https://auth0.com/docs/architecture-scenarios/spa-api)
Basically what we can do is when Auth0 authenticates the user it redirects the user to the app with an access token, and optionally an id token, in the hash fragment of the URI. We can extract that and use the token to call the API on behalf of the user.
So, after we have [created the API in Auth0][3, [defined the endpoints]3, and secured the endpoints we can call the API (by sending the access token in an Authorization header using the Bearer scheme).
If you have any Auth0 specific question please feel free to join over in community.auth0.com you may have better luck finding help/solutions.
The 403 error is telling you that the request is not being processed because something is stopping from process that request 403: The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated
As you said probably because the CORS, try to follow the guide bellow of how to install Django-cors
https://github.com/mbrochh/django-graphql-apollo-react-demo#add-jwt-authentication-to-django
I'm having problems with Get New Access Token for Postman and SmartSheet.
All URLS are prefixed with https:// but StackOverflow would not allow that.
Callback URL: www.getpostman.com/oauth2/callback]
Token Name: Test
Auth URL: app.smartsheet.com
Access Token URL: app.smartsheet.com/token
Client ID: used the one provided when registering my app with SmartSheet
Client Secret: used the one provided when registering my app with SmartSheet
Scope: blank
Grant Type: [Authorization Code]
When I click Request Token it takes me to the SmartSheet Login. After I login and close the SmartSheet browser I get Could not complete OAuth 2.0 Login.
Looking at your example the Auth URL is incorrect. That should be
https://app.smartsheet.com/b/authorize
Also, the Access Token URL should be
https://api.smartsheet.com/2.0/token
The Smartsheet OAuth2 flow also requires a Scope, so it can't be left blank in spite of what Postman says.
More information on all of this can be found in the documentation:
http://smartsheet-platform.github.io/api-docs/#oauth-flow
It is important to note that with all of this set correctly setting this up in Postman still won't work. This is due to the fact that the Smartsheet process of obtaining and refreshing the token Smartsheet requires clients to hash the authorization code (with a pipe and the app secret, using SHA256) rather than sending it in clear text. This is arguably non-standard, but is still within the OAuth2 spec. More information on this process is at the documentation I referenced above.
Unfortunately, it does not look like Postman supports these types of deviations from "vanilla" OAuth2. Depending on what you are trying to accomplish, you will either have to go though the steps of the process manually, or stand up a third-party app in a hosting environment. If you are simply looking to generate a token, this approach http://smartsheet-platform.github.io/api-docs/#direct-api-access may work for you instead.
If you are trying to test in Postman the Direct API approach works. http://smartsheet-platform.github.io/api-docs/#direct-api-access
Step 1) Go to your actual smartsheet "https":"//app.smartsheet.com/b/home" and under Account>Personal Settings>API Access -- Generate a token (copy it you wont be able to copy after you close)
Step 2) Get the url for your sheet. Right click on the sheet name tab and select Properties. Copy the the Sheet ID (ie 123456). Add it to the end of the url: "https":"//api.smartsheet.com/2.0/sheets/123456"
Step 3)The most confusing one in my opinion. In Postman select No Authorization. Then go and update the header with "Bearer 0da6cf0d848266b4cd32a6151b1". You have to have the word Bearer and the randomly generated string of numbers is from Step 1.
Then send the get request and you get your sheet back in json format.
I'm writing an Android app which will authenticate itself using OAuth2 to a Web server under my control.
I'm using Apache Amber on the client side, and oauth2app with Django on the server side.
From the client, I can generate an authorization request, and start a browser Activity that goes to a page asking whether to allow the client access, and after answering in the affirmative, redirects to a page with a "code" parameter.
But how do I get the "code" back to my client, in order to make the subsequent access_token request?
Do I need to bypass the browser entirely? How would that work?
I believe you have a couple of choices here.
The redirect_uri parameter will indicate to the server where it should send the code.
From the ouath2app docs:
If a request is authorized, Authorizer:grant_response() will serialize an object into a JSON response will return a redirect response to the client’s redirect_uri with information on the authorization code passed as query string parameters (response_type CODE) or access token passed as URI fragments.
So armed with that:
If that value is a location on your server, then your mobile browser is going to get the value as part of the redirect. Specifically, you're trying to read the URI fragments in the redirect. I believe this is the intended usage for an application like yours. This blog post seems to have code that might be relevant, under the section "Retrieving the access token".
Alternatively, as you pointed out, you could send the token to a different handler on your server, and then pass it back to your client. It must the callback URL defined in the service.
I found a different blog post, specific to OAuth 2:
http://blog.doityourselfandroid.com/2011/08/06/oauth-2-0-flow-android/
The trick is to fire up a new Activity whose content is provided by a WebView (rather than a layout). You can attach a handler to the WebView that's called on the redirect to the page containing the "code" parameter.
Some of the specifics in the blog post concern Google APIs, but so far my experiments suggest that it will work in my situation.