I have a graphql server, what is working with jwt auth.
The problem: The playground sometimes sends the Authorization header, sometimes not.
Not sends: on the AWS server.
Sends: Localy.
If im hitting the aws server with postman it also works, but the dev speed would be much better with working playground.
If You checks the Network tab, the Request Header should contain the Authorization token, but the is no Authorization entry, instead the token sent in Request Payload.
You can test it out: a link
Related
I am using keycloak to authenticate my Apollo server express API. Including the bearer token in the Apollo studio header is not enough to authenticate the studio as the request needs to contain certain cookies provided by keycloak that are set in the browser when I log into the front end app.
The front end sends this cookie along with the bearer token to the server. While I have the option to manually define an authentication token in Apollo studio, I don’t know of a way to attach the cookie to the request.
Interestingly enough, when I use postman to query my API, postman will actually extract the cookie in the browser that has already been set by logging into the front end and include it in any postman requests to the URL that corresponds to the cookie, so I can make authenticated requests with postman if I have already logged into my front end. Unfortunately Apollo studio does not do this.
How can I provide Authentication with the cookie from my Apollo studio? It’s a bit tricky since Apollo studio is not hosted by my backend application. Can I have express middleware to insert the cookie in requests coming from Apollo studio? What would this look like?
I’ve also heard talk about creating a proxy but I don’t really understand this option, is this a viable solution and how would it work?
I am trying to do API Testing by JMeter in two steps:
1. Generate Acess Token
Here, the authentication request is getting timed out.
Authentication Type: OAuth2.0
Grant Type- Client Credentials
I am passing the token URL and grant_type, client_id and client_secret in the Parameters section like this:
But I am getting the following error:
2. Hit the API with the fetched token
I am able to hit this with a token generated from POSTMAN.
Also in POSTMAN, I am able to authenticate properly. I tried recording the POSTMAN script but the authentication flow is not getting recorded. Just the GET API is working.
Is there any way to get the token in JMeter? or any other workaround?
Given you send the same requests you should get the same responses so capture the requests originating from JMeter and Postman using an external sniffer tool like Fiddler or Wireshark and compare the them.
The requests must be exactly the same including:
URL
Request Body
HTTP Headers
Inspect the requests and amend JMeter's configuration so the request would be 100% equal to what Postman sends.
Also it's possible to record Postman request or collection execution using JMeter's HTTP(S) Test Script Recorder
And last but not the least check HTTP Proxy settings for Postman, it might be the case you need to use a proxy server for accessing the authorization endpoint and the connection to the application under test is direct, Postman has proxy configured and JMeter doesn't, if this is the case - perform JMeter Proxy configuration again to match 100% Postman settings.
I'm setting up a service which needs to authorize against an existing Gitlab as OAuth Provider.
The service is a SPA which gets served by a webpack dev server in dev mode and a nginx server in production mode.
I'm also setting up an external API which should handle the Database and make request to the given gitlab instance (for example pull repos).
My SPA is authorizing against the Gitlab OAuth with the implicit_grant flow and is getting an access token. Currently I pass the access_token after the redirect to my API backend and there I get the Gitlab userid and username via a request to the gitlab instance with the access_token. With these I generate a jwt and send it to the client (SPA) and save it there so I can authorize my API with this JWT.
How would I handle the initial access_token in my backend (cause I need the token to make gitlab calls)?
Currently I'm thinking about writing it to the user in the database and get the user everytime he makes a request (normal passport flow), so I also have the token. But what if the token gets invalid or expires?
Should I use an interceptor in the backend and if the token is invalid (gitlab would give me a 401) redirect the 401 to my client, let him get a new token and pass it back to the backend, generate a new JWT, send this again to the client and let him do the same request as original reuested(via interceptor, too)?
Or should I just redirect the 401 to my client, let him get a new token, let him post this token to for example /renewToken and save the token to the database and use the old JWT?
Hope someone can help me unserstand this flow.
The Credential Management API should be what your looking for on the client. That will retrieve the id and access tokens to that you can compare access tokens with your server/ap and then validate the id token.
Haven't seen a Git example but there are Google and Facebook examples.
You could let the user send the initial access token and your backend API will just act based on the initial access token. Seems to me that it is not necessary to produce another JWT token in this case.
A new website I'm working has the following components:
AngularJS/HTML5 Front-End
Web API Back-End that supports Front-End
OAuth Server - Authenticates user and provides tokens
The workflow for an unauthenticated user:
Views Front-End, which calls Web API to determine if authenticated
If not authenticated the user is redirected to OAuth Server
After successful authentication, the browser is redirected back to website with Auth Code
Auth Code is sent to Web API
Web API logic requests Access Token from OAuth server
A cookie is used to associate the token to the user
Additional requests send the cookie, which is used to authorize the user.
My question is what should I send for the HTTP Status Code for Step 1? Normally you send 401 for not unauthorized, but that is if you are using HTTP Authentication. Since the authentication is handled by a different server, that wouldn't make sense. 403 doesn't seem correct either because it implies a that the status will not change.
Should I just use a generic 400 or a custom 400.X code?
Although there is nothing wrong with sending HTTP 401 Unauthorized as a response in your case, a much better alternative would be to send HTTP 302 Found, which would imply that when the user was trying to access the front-end view, the applicable resource in this case (OAuth Server Url) was found somewhere else.
You can mention the OAuth Server Url in the Location header of the response, so the client would redirect the unauthenticated user to the intended location.
HTTP 302 Found
Location: https://oath-server-url.com
I'm building an Angular app with an API backend. On a combination of pieces of advice, I built the API with a flavor of token authentication. The flow is roughly as follows:
POST to login endpoint with credentials
Validate credentials and authorization, then generate a new token
Return token to client
Client uses token via HTTP Basic to access API resources
This is all working well. The problem arises in creating a session based on this token. I don't believe I should simply hold the token on the client in a cookie, but I do need a session to persist between page refreshes, etc. My Angular app is stateless and completely populated via API calls.
I'm looking for a recommendation as to hanging on to this token on the client. I feel there's danger in holding the token in a cookie because the cookie could be stolen and simply used to authenticate as someone else, but perhaps this is incorrect.
Thanks in advance for your assistance!
The only known way for me to identify a user is to use some token on the client.
HTTP is stateless and can't know which request is coming from which user (browser). You can't identify the user by his ip address (many users are behind a router and share a connection). You could try browser fingerprinting, it can work on some browsers but not on all.
I would recommend using a cookie to store this token on the client.
They are send to the server on every request and you can do some protection to keep them from getting stolen.
To protect this cookie from man in the middle attacks you need to use an encrypted connection over HTTPS to the server.
Set the following attributes on the cookie:
HTTPOnly: cookie can't be accessed by javascript (XSS protection)
Secure: cookie will only be send over https
Path: cookie will only be send on specified path e.g. /login
I would also define an expiration date on the cookie, so the cookie is invalid in like 2 days or something.
But you are right. If this token gets stolen someone else can login as this user.
Since its an Angular app, I'd assume all authenticated methods will only be served to ajax requests (you can tell your server to only respond to ajax) in which case CORS will help you.
The only way to be completely secure is HTTPS, however this method is probably more secure than you think. Read up on CORS a bit for more info, but essentially the idea is that servers will only respond to ajax requests coming from html pages that were served by that same domain.
Pre-flight OPTIONS requests are often sent to verify this. The browser sends an OPTIONS request with an Origin header (the origin of the page) before the actual request. If the origin matches the domain of the server receiving it, the subsequent request is allowed. Otherwise, it violates the Same Origin Policy and will be rejected.
This prevents someone from sniffing out the token and sending a request with the token from a page that your server didn't serve (like something running on the hackers local machine).
If you are doing credit card transactions or anything super secure, you should use HTTPS though.
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing