So having figured out how basic authentication in Web API works with ssl, I want to do the following:
After the client is authenticated, send the client a token (righ now i am thinking that this should just be GUID) with some expiry date, after which the token would render useless and the client will have to authenticate again.
My problem is knowing how the client would send this token in subsequent requests? Should it be sent in:
a) json payload or
b) part of header
If a) then how about GET requests that do not have a body and therefore no json payload?
If b) then what should it be called in the header...or I can just call it anything? Like, authToken: Asdhad-asdlad-82hjf-adkga
Also, since I am using ssl, I do not know if its better to use token or just use user credentials?
Enlighten me on what the standard is here or am I going in the wrong direction?
Thank you.
put the token in the authorization header and name it: "bearer ej304305340Mytoken". SSL is used for authentication of user + password and the subsequent requests with the token.
Related
Can someone tell me how to send jwt authentication token for every rest request send from asp.net core to the web APi,
Does there is need to create a secret key to sign the token signature?
Can we just send the token without signing the token.
This is very broad question.
Short answers:
Tokens are usually sent in cookies. Certain solutions also store tokens in browser localstorage or sessionstorage and then add the token in every request header
Yes, signing the token is mandatory. Otherwise, the server won't have a way to determine if the token has been tampered by an attacker or client. Signing is required for security
But there are much more to it. Refer to the following for details:
https://stackoverflow.com/a/54258744/1235935
https://stackoverflow.com/a/54011649/1235935
https://www.rfc-editor.org/rfc/rfc7519
https://www.rfc-editor.org/rfc/rfc6749
I have a couple of days following a few issues but I can not find the solution .
I have followed these issues: Custom JAX-RS authorization - using JWT in each request and
Best practice for REST token-based authentication with JAX-RS and Jersey
but I do not understand how to use filters.
I need to create a token for a android app Use the resources of my web service.
I can not just create a token and send it ?
I 'm using jjwt https://github.com/jwtk/jjwt but I think it right, a piece of code:
#POST
#Produces("application/json")
#Consumes("application/x-www-form-urlencoded")
public Response authenticateUser(#FormParam("username") String username,
#FormParam("password") String password) {
try {
// Authenticate the user using the credentials provided
// authenticate(username, password);
// Issue a token for the user
String compactJws = Jwts.builder().setSubject(username).signWith(SignatureAlgorithm.HS512, "pepe").compact();
// Return the token on the response
return Response.ok(compactJws).build();
} catch (Exception e) {
return Response.status(Response.Status.UNAUTHORIZED).build();
}
}
If anyone can help me , thanks ...
Si alguno me puede responder en castellano, mejor.
PD: Sorry if I asked the question wrong, I'm new in stackover... and sorry for my English
I am the author of the answer about token-based authentication in JAX-RS. This authentication method can be summarized in the following steps:
Exchanging hard credentials for a token
No filters are required to do it. You should have an endpoint (a JAX-RS resource method) to perform the authentication using hard credentials (like username and password). If the credentials are valid, the endpoint is going to issue a token that will be sent to the client in the response payload. The client must sent this token in the Authorization header of each request.
The endpoint that issues the tokens must not be protected, that is, no authentication must the required to access it. Once you have an Android application as client, I think you will find better consuming application/json instead of application/x-www-form-urlencoded. My answer provides details on how to do it.
Validating the token
Here the authentication filter comes into play. When using filters to validate the tokens, you can keep your endpoints lean and business focused.
The idea behind the filter is to intercept the requests to protected resources, extract the token from the Authorization header and validate it. If the token is valid, the request will proceed to the requested endpoint. If the token is invalid, the request will be aborted.
Besides the authentication filter, you can have other filters to perform authorization, for example. In the authentication filter, you must check if the token is valid and then find the user you issued the token for. In the authorization filter, you must ensure the user has enough permissions to access the requested resource. Other filters can be created according to your needs.
The code you have provided is valid to a issue a new token for a web application (uses application/x-www-form-urlencoded), but for android application It would probably be more appropriate send credentials as a json POST or in a Authorization header
After this, the client application receives the token, stores it and needs to include the JWT in every request to server. You can include the token in headers or in a request param. The server must validate the token signature, and other fields like sub (the userId) and exp (expiration time).
Using a filter, like the AuthenticationFilter provided in the example, simplifies the authentication process. It can intercept all the requests and perform the validation in a unique point. If not, you would have to validate the JWT in each method of your bussiness logic
If you have doubts about how to configure the filters I suggest to post in SO an specific question
I'm currently in the process of developing an API but I am slightly stumped on how I'd go about securing it. I don't want to reinvent the wheel, and I'm not an expert on cryptography.
My current plan would be as follows;
Check if the client is communicating over HTTPS
Check if the client has a token, if they do then validate it otherwise get them to login (return a 401)
To validate the token I would check if it exists in the database and if it does check it hasn't expired.
If the token doesn't exist, I would ask them to authenticate. This would involve sending their username and password to the server over HTTPS, I would check it using a traditional approach (hash it, salt it, compare it etc.) If it all checks out, then I'd create a session key/token/random string and in all future requests ask them to send it with their API request.
Does this sound like a sensible approach?
Thanks
You could opt to use single sign on and delegate the token generation to a Security Token Service, like Thinktecture's Identity Server.
Then on the API side, you will just have to configure Bearer token authentication, something like this:
app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions
{
Authority = "https://localhost:44319/identity",
RequiredScopes = new[] { "sampleApi" }
});
complete example here: https://identityserver.github.io/Documentation/docs/overview/mvcGettingStarted.html.
That sounds ok to me for starters. What you are thinking of is Basic Authentication followed by Token based Authorization. But you should also consider having some kind of obfuscation technique for sending username and password. Like base64 it in a specific format that only your algorithm can decrypt on the server side. Here is a good tutorial that should help you: http://www.codeproject.com/Articles/1005485/RESTful-Day-sharp-Security-in-Web-APIs-Basic
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
I'm constructing an application with 2 sides: client (iPhone) and Server (PHP). Communication using https. The mobile phone gets a 4SQ access token. Then, it sends that token to the server, and the server will make 4SQ API calls using it. My question is about how to send this token.
My idea was to include the token in the HTTP Authentication request's header, but after reading about basic/digest authentication, I suspect it isn't the way of doing it. Actually, the calls to 4SQ API are done using a request parameter
oauth_token=ACCESS_TOKEN
instead of putting the token in Authentication header, or any other place. I'm sure there's a good reason for that, but I can't find it.
Then, which option is the best?
Phone sends token to PHP server as request parameter, like 4SQ does
Phone sends token to PHP server in Authentication header (which kind oh authentication is?)
Any other way
Many thanks in advance, and best regards
I think the most secure and reasonable way would be a HTTPS POST. When the token is part of the query string in a HTTPS request, it is also encrypted. But it will appear clear text in the server log, or, when a browser is used, it could also appear in the browser history. Depending on the HTTP helper library, it could also log the HTTPS URL, when, for example, a request fails.
In my eyes, sending the token in the Authentication header would be strange, since it is not used for authentication between the server and the client.