I am using Postman to test my GraphQL layer and Postman has a handy GraphQL designer for the BODY of the request. It also has a nifty feature for doing a Schema Fetch
If your GraphQL endpoint is secured with OAuth, you normally set the Authorization page to pass the token. All good so far.
However, if your authorization token is set as a collection / environment variable, it does not work because the translation from variable to content does not appear to be happening
How to reproduce.
Create a Postman collection / environment variable for your token (it can be anything for now)
Open your GraphQL request
Switch to the Authorization tab
Set the Authorization Type to Bearer Token
Set the Authorization Token to {{variable-as-per-step-1}}
Switch to the Body tab
Change the body content type to GraphQL (This will then show "Fetch" buttons)
Click the refresh button for the fetch
What happens is that this sends the Authorization header as Bearer {{variable-as-per-step-1}} to the endpoint, it does not substitute the variable with the actual content of the variable (which it does when you SEND the request.
If you update the Authorization Token to an actual value (rather than variable), then everything works as intended.
Related
I am learning OAuth 2.0.
In both code flow and implicit flow (response_type = code or token). The temporary code or access_token is placed in the URL fragment (after the #) instead of in the query string.
According to this doc: https://developer.okta.com/blog/2018/05/24/what-is-the-oauth2-implicit-grant-type:
If the user approves the request, the authorization server will redirect the browser back
to the redirect_uri specified by the application, adding a token and state to the fragment
part of the URL.
For example, the user will be redirected back to a URL such as:
https://example-app.com/redirect
#access_token=g0ZGZmNj4mOWIjNTk2Pw1Tk4ZTYyZGI3
&token_type=Bearer
&expires_in=600
&state=xcoVv98y2kd44vuqwye3kcq
Note the two major differences between this and the Authorization Code flow: the access token is returned
instead of the temporary code, and both values are returned in the URL fragment (after the #) instead
of in the query string. By doing this, the server ensures that the app will be able to access the value
from the URL, but the browser won’t send the access token in the HTTP request back to the server.
What exactly does it mean by
the server ensures that the app will be able to access the value from the URL, but the browser won’t send the access token in the HTTP request back to the server.
?
Of course the code/ access_token value is accessible from the URL.
The Auth server builds up the url and put it in location header of the HTTP response, which is sent back to the user's web browser. The web browser then take values from the response, and send new http requests to the application instead of the Auth server. So, of course the user's web browser is not sending HTTP request back to the server.
It has nothing to do with where the access token is placed in the response (from Auth server back to the user's web browser). The web browser simply starts talking to the application again instead of the Auth server.
This explanation just does not make much sense to me.
The code flow returns an authorization code to the browser in the query string. You then make a POST request to swap the code for tokens.
https://www.example.com?code=xxx&state=yyy
Implicit flow is now deprecated since it can reveal tokens in the browser history or server logs. It dates back to when browsers did not have CORS capabilities to make cross orign POST requests to the Authorization Server.
Data in client side hash fragments does not get sent to servers and the implicit flow used this as a partial mitigation for sensitive data. Eg the zzzz below does not get sent to the web server if you type this in a browser.
https://www.example.com#zzzz
If you are new to OAuth and OpenID Connect, start with code flow + PKCE, and understand these messages.
SWAPPING THE CODE FOR TOKENS
This is often done via a back end component that completes the flow, so that a client secret can be attached (a browser cannot keep secrets). This back end component can then do either of these:
Return access tokens to the browser
Issue secure cookies to the browser
Once done, the front end has a credential with which it can call the main back end (eg APIs), so that the back end knows the user identity.
CODE EXAMPLE
In 2021 the cookie option is considered more secure, but it also requires a more complex flow. All of the complexity involved originates from the browser being a hostile place to execute code - there are lots of security threats there. Here is some example code that uses cookies:
OAuth calls from an SPA
API calls from an SPA
I'm trying to understand OAuth 2.0 which is scarcely, badly documented and I'm trying to implement OAuth 2.0 client call in my App. I am using Postman to simulate API calls, which works. Postman shows big orange button "Get New Access Token", where I select Grant Type, URL, Client ID, Client Secret, Scope and Authentication type. Upon clicking button Request Token, new bearer token is returned by the API, meaning the authentication succeeded. This of course is completely useless approach to me, because I have no idea what just happened. I need to create actual request that shows me exactly how it is formed, so that successful response with bearer token is returned. Postman, for absolutely no reason, will not let me see that or convert it's useless UI into a functional API request. All I have is black box with orange button "Request Token", which does who knows what.
Does anyone know, how to form a working OAuth 2.0 bearer token request in Postman, preferably to convert their useless token request dialog directly into a request?
After some research I have been able to form a valid OAuth2 token request. For clarity, here is a code sample, which we need to convert to Postman response:
var client = new RestClient("https://api_address/token");
client.Timeout = -1;
var request = new RestRequest(Method.POST);
request.AddHeader("Authorization", "Basic hash");
request.AddHeader("Content-Type", "application/x-www-form-urlencoded");
request.AddParameter("grant_type", "client_credentials");
IRestResponse response = client.Execute(request);
Console.WriteLine(response.Content);
The hash part of the request is formed from client_id and client_secret values. In Postman, this is defined as such:
Create a simple POST request with token API url.
Go to Authorization tab.
Select Basic Auth
Enter client_id and client_secret into corresponding fields as username and password.
Go to Body tab.
Select x-www-form-urlencoded.
Enter key grant_type with value of client_credentials.
This example is for the client credentials flow. OAuth2 authors felt that calling auth scenarios as auth scenarios isn't cool enough, so they are called flows, which is nonsense, but sounds cooler.
Process one:
Process two:
First, determine whether your token is passed through the header
It could be:
else process:
I'm trying to set up Pac4j in my back end (BE) application and in order to configure my Angular front end (FE), I need to understand the workflow that it expects in order to configure the back end properly.
I've been reading reams of documentation and trawling through Pac4j source to find how I get the token from the code without exposing the client secret.
So...
I try to log in FE->BE (without auth)
I receive a 401
I take the 'Location' (the Google auth uri) from the 401 and redirect to it, providing a callback uri
I log in to Google
I am redirected back to my callback uri with a code
(What request do I make to BE in order to get a token back? i.e. where is the token URI that doesn't require a client_secret)
I use the retrieved token to access and continue as normal using BE
If you don't want to use client_secret, then you need public client. I'm not sure if public client is supported by Google.
IMHO better approach will be implicit flow in the FE. It will generate access token, which will be used for BE api calls.
I have an angular app that I need to redirect outside to a server side html page, so I thought I could just use a standard <a> tag with target='_self' to redirect the angular app to my server side page. This actually works fine, however, I have a rails backend that checks for auth token before serving up any content.
This requires a auth token to be sent in the header of the http request which I am setting in a cookie, and angular grabs automatically with the $http service for ajax requests, but I can't seem to get the same thing to happen on a standard link.
Can/How do you add an auth token to a normal link before it is sent off?
When the browser is making the HTTP request and not your JavaScript code, you cannot add a custom header with your token value. See Adding http headers to window.location.href in Angular app for a similar question.
However, if this value is already being sourced from a cookie, can your backend just read that cookie value (or use some filter in the http request chain to transfer the cookie to a header)?
I'm working with OAuth 2.0 for MVC, found here: http://community.codesmithtools.com/CodeSmith_Community/b/tdupont/archive/2011/03/18/oauth-2-0-for-mvc-two-legged-implementation.aspx
For anyone who's worked with this - I'm confused about the RequestToken. There is a controller implemented that lets you get a request token, which expires in 5 minutes, and you pass that token back in to get an AccessToken. But it never checks the request token for validity - it seems like you can pass in any access token you want to. What is the idea for the RequestToken here - are you supposed to create your own method of storing, referencing, and then deleting that token for those 5 minutes?
Thanks,
Andy
This is all about how OAuth works in conjunction with your application Id, application secret key and valid domains for your application. Here is the process in general
Your application sends a request to the OAuth provider using your application Id and secret along with a callback (return Url).
The OAuth provider gets the request, checks your application Id and secret and validates that the callback url is from a domain that you have specified for your application.
2a. If the callback url is not from a domain that you have specified, then the request is rejected with error.
2b If the callback url is from your domain, it returns a temporary request key to your server.
Given that you received a request key, you send that back to the OAuth provider to get the actual access token for the user.
Now, as to why the request key step is in place, this is to prevent and help protect 'bad people' from attempting to use your application id to falsely authenticate other users. By sending the request token to you (a callback URL that you have approved), the OAuth provider has confidence that the request actually came from your servers.
You most certainly could send any string back instead of the request token, but you would quickly get an error back from the OAuth provider as that request token does not correspond to any existing authentication request from any known application.
Lastly, I am not clear on what you mean by 'validating the request token'? You did not generate the token not probably do not have insight into the algorithm to generate the request token. Given that, I am not sure how you would validate this. If you are concerned about validating the first step, take a look at the Facebook OAuth process. In there, they recommend sending a request key as part of your return Url(as a query string parameter). That request key will come back to your application which you could then use as a validation that, indeed, this is a response to a request that you made. How you store and track that request key is up to you (session, database). In the PHP samples, they use a 'state' variable to track a unique/arbitrary string: Facebook OAuth Server Side Login Example (in PHP)