I'm building a REST service and right and have run into a problem. Right now the functionality is this: a user can post their username and password and if it's correct I return a JWT token for them.
What do I need to do in order to make a client use this token when they request something from a protected endpoint? I'm new to web in general and I don't know where to go from here.
First, you have to save the JWT somewhere. In a browser, the best options are in cookies or local storage (see where to store your jwts for an example on how).
Second, you need to pass the JWT back to the server with your next request. You will have to retrieve the JWT from wherever you stored it and include it in the request. How you do this depends on where the server expects your JWT to go and what framework you use for making requests. For example, if your JWT goes in one of the request headers, here is an example for setting request headers with a jquery ajax request.
Related
I am creating a simple API database using an xAgent, Another application is requesting data by sending in a query in the request headers and I process the header and send back the requested data, so far so good.
I now need to add some sort of authentication to this request. but without using Domino authentication. if I use postman and send in a username and password as "basic authentication" that is not correct Domino sends back the following:
nHTTP: user [xxx.xxx.xxx.xxx] authentication failure using internet password
So if I send in username and password in a Basic Authentication request, Domino will try to login the user to Domino. However I do not want to do that.
I want to provide my own username and password that the request must match to get the data. (So if correct username/password is sent in I will send back the data anonymously to the user)
I am guessing that using Authenticated requests feature will somehow make it safer.
Can I set Domino to ignore the authenticated request for my application so that I can handle it in code?
or should I just let the external application send in username and password in the request header as base64?
advice needed
thanks
Thomas
Just use another header (it is YOUR Api), i.e. X-Auth and handle it by yourself.
But keep in mind that this lowers the security if you make a mistake...
I set up login in web application with ADFS.
Authorization request looks like:
https://sso.company.net/adfs/oauth2/authorize?response_type=code&client_id=ruleman&resource=urn:ruleman:1&redirect_uri=http://ruleman.net/authorize
ADFS performs authorization and redirects to the app:
http://ruleman.net/authorize?code=aaaaaaaa.bbbbbbbbb.ccccccccc
One knows that the token from code parameter contains claims such as username etc. How to decode the token and extract the claims?
The Postman flow for this - refer Postman : Authorisation Code Grant on Server 2016 - ADFS 4.0.
This code grant is the flow you have described.
As per the other answers:
Use the authorize endpoint
Get the code
Send the code to the token endpoint
Get the JWT
Use jwt.io to examine the JWT.
The flow follows the OAuth 2.0 standard. Please note I am not expert in ADFS, however I know OAuth 2.0 well.
The authorization flow consists of multiple options with different steps. In your case you are using the code profile (specifying response_type=code). The authorization step you did is only first step, there are a few steps to follow
you can search on "OAuth 2.0 with ADFS" e.g. http://blog.scottlogic.com/2015/03/09/OAUTH2-Authentication-with-ADFS-3.0.html
Authorization request
../authorize?response_type=code&client_id=ruleman
&resource=urn:ruleman:1&redirect_uri=http://ruleman.net/authorize
you will receive an OAuth code (usually not aving any information value, it is only a code)
http://ruleman.net/authorize?code=aaaaaaaa.bbbbbbbbb.ccccccccc
code parameter contains claims such as username etc
This is wrong assumption
Using this code you need to call a token service from backend to receive an access token (e.g. using HttpClient).
POST /adfs/oauth2/token HTTP/1.1
grant_type=authorization_code&client_id=some-uid-or-
other&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2FgetAToken&code=thecode
you will receive an access token. This step ensures you application is really authenticated with the identity provider it knows.
According to the post linked above:
The interesting bit is the itself, it is in fact a JSON Web Token (JWT). That’s to say a signed representation of the user’s identity and other grants.
I am unable to confirm that, but you can try. Usually (with other identity providers) the token is only a token and the client neeeds to call a "user information" service to get any user identity claims, however seems the ADFS gives you some shortcut.
Then you can use any JWT library to decode/validate the jwt token (com.auth0/java-jwt/3.0.1)
com.auth0.jwt.interfaces.DecodedJWT jwt = com.auth0.jwt.JWT.decode(token);
What I'm trying to do
Right now I'm working on a Java Spring Backend for a Both which manages the request he gets from a NLP from api.ai and gives back corresponding information. Now I'd like to interact with different services that use OAuth2 to get information/data from there as well.
What I did so far
I have added my credentials for the service in my application.properties file. But only found a solution that a user can for example log-in with his facebook credentials on my service.
But I need to have my service to authenticate on the other service (with the given credentials from my properties file), to gather data from there.
Do you guys know a solution, tipps, tricks for that?
As I understand the logic should be following.
As you have SSO (OAuth2 based) you need to login just once and get token(s) from OAuth2 service (access token and refresh token). The access token is included in the request headers when you call any of your services.
Now Service1 must call Service2 using the same auth info.
In the Service1 you call OAuth2 service to check whether the token is valid. If yes all you need is to use the same token to call Service2.
So just extract the token from request headers and add to the headers of request you send to Service2. Could be done e.g. by adding a Filter and storing the auth info in a ThreadLocal variable (or inheritable ThreadLocal if you generate new threads by e.g. running Jobs).
Service2 in turn also checks the token by calling OAuth2 service but the token is valid.
For me that's all you need.
I'm writing a standalone application with accesses the Adwords API. The oauth2 authentication and authorization works fine.
My problem is that I want to save the refreshtoken in a textfile and use it directly the next time I run the app to restore my credentials. The refreshtoken should be valid for 14 days, so restoring the access credentials would very good.
I haven't found an example which works. Can someone help?
The refresh token is not much different from the authorization tokens.
OAuth2.0 has several flows that can be used to get access to the servers. The common (and savest) flow is the so called Authorization Code Flow (detailed info here).
There your application asks the authorization server for an authorization code the first time the user wants to use your application. The user will get that authorization code over the website when he logs in and grants your application access to the service. Your application sends this code to the authorization server in order to get the first access token(and with it the refresh token). It is the same server you need to send the refresh token to.
Now, I don't know exactly what the server's uri is in your case, but this would be an example of a POST request you can send the server:
POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
client_id=YOUR_CLIENT_ID_HERE&
client_secret=YOUR_CLIENT_SECRET_HERE&
refresh_token=THE_REFRESH_TOKEN_HERE&
grant_type=refresh_token
If the request is valid, the server will respond with a new Access Token. Here you can find more informations about the specific requests you can make.
Keep in mind that every token (access- and refresh tokens) have to be stored savely. The best way to do this is to save it encrypted and when sending the tokens use only POST requests and https. But this wasn't your question.
I hope I could help you with this.
HTTP specification says;
HTTP access authentication is described in "HTTP Authentication:
Basic and Digest Access Authentication" [43]. If a request is
authenticated and a realm specified, the same credentials SHOULD
be valid for all other requests within this realm (assuming that
the authentication scheme itself does not require otherwise, such
as credentials that vary according to a challenge value or using
synchronized clocks).
I don't really understand what this means, but here is my scenario is there anything against HTTP specs here? I use Java Rest service
Client sends username:password using HTTP Authorization header using HTTP Basic
Server sends back a token
Now client sends a custom authorization token instead of password for further requests still in the HTTP authorization header still using HTTP Basic username:token
Now this does not feel right since what I am really doing with the auth token is NOT an actual HTTP Basic authorization. Also usage of the very same header is inconsistent between requests.
But on the other hand I do not want create yet another custom header for the token exchange. Because its hard to base64 encode them with test tools when you use a custom header. And still inconsistent headers between requests.
Note: these requests refers to different endpoints
What do you advice?
If you do that, since you are using the same headers, aren't you going to need server side logic to differentiate when the login is the actual login, as opposed to your token? At the end of the day, HTTP Authorization is already a token (only a simple encoded version of the username/password string), so in all cases you are receiving a token, now you have to decode it, decide if it's one of your session tokens, or if it's a username/password, and therefore check against two sources of "good tokens".
I would advice against this, but not because you're breaking standards, it just feels convoluted.
Why do you need to change username/password to a token on the first place? Are you redirecting to an endpoint where you no longer require HTTP Basic Auth?