I am struggling a little with how I should implement a user authentication management in Ember JS. I would like to start with a very basic implementation.
# database table
users
-----
username, password, token
When the user attempts to sign in, they would provide credentials (username, password). The API which is requested should return a token and this token (in a header) should be used in every subsequent http request.
Couple of questions here:
Where do I store the "token". Is there a local store management?
I know I could use this.get('store') although this ties with the "api server data source" as well
Any direction would be appreciated!
Thanks!
Related
I have implemented google-signin using the oauth2 from Angular Application.
Once authentication is successful and the token is generated, I am storing it in the LocalStorage/IndexedDB and also trying to send this Token, UserProfile info etc, to my flask-backend.
I would validate the token and continue the flow
Now, I want to use the user bearer token as my Session-ID, i.e, each API call I am doing, I will be doing by validating against this bearer token.
I believe by doing so, I will be able to avoid 'creating sessions' and also leverage the google-generated tokens for uniquely identifying users and the calls to backend.
Please let me know what security flaws this would give rise to and also what are the alternatives for the same
Although at the point of time I was making the question, it was a bit unclear on how to proceed, heres a summary of what I have accomplished -
1 - I have used Angular for frontend and I have refered this page
2 - While doing so, my doubt was how would I proceed with user authentication and how I would continue to register the user and get the required details like profile, contact, address etc.
What I have done ->
Once a bearer was issued, I was passing this info to backend and then, from the backend, I was reaching out to various google api's and getting relevant info with the bearer.
Also this bearer was being stored on client end so as to ensure UNTIL the token expires, I would continue to not issue another token and meanwhile, as and when the user session times out, I would read the locally stored(client side) token and validate it on backend,
should the token be valid, backend server would go and all the info for all the scopes, and deal the other flows accordingly.
I'm creating an API server which will be consumed by a mobile app that I will work on later. I have yet to see any reference of API best practices related to user flow and returned data even after searching for several hours.
My question is whether the login response of an API should return the a personal access token with the refresh token along with the user info? Or should I just return the token and make another API call for getting the user info.
I could just do what I have in mind but I'm trying to learn the best practices so that I don't have to adjust a lot of things later.
I need suggestions as well as good references related to my question.
Thank you.
It depends on what you are using for your authentication. If you are using libraries like Laravel Passport or JWT, you can have the token endpoint which returns the access token, refresh token, validity period and the token type (Bearer). You can then have an authenticated endpoint which will be used to get a user's profile based of the token passed in the request header.
However, if you go through the documentation for those libraries, in most there is an allowance to manually generate a token. You can use this in a custom endpoint that will return the token as well as the user profile Passport Manually Generate Token.
If you are using JWT, you can also embed a few user properties in the token itself. The client can the get the profile info from the JWT itself without having to make a round trip to the server. Passport ADD Profile to JWT
If you have a custom way in which you are handling authentication, you can pass the token as well as the user profile in the same response.
In the end, it's up to you to decide what suits you best.
Have you looked at OpenID Connect? It's another layer on top of OAuth 2.0 and provides user authentication (OAuth 2.0 does not cover authentication, it just assumes it happens) and ways to find information about the current user.
It has the concept of an ID_token, in addition to the OAuth access token, and also provides a /userinfo endpoint to retrieve information about the user.
You could put user information in your access token, but security best practice is to NOT allow your access token to be accessible from JavaScript (i.e. use HTTP_ONLY cookies to store your access token).
I am using MEAN stack for developing a web application. I choose it be completely RESTFULL that is stateless. For authentication I am using JWT(Json Web Token) strategy.
Client sends login request to server, server authenticates and sends JWT and user data to the client(here angular 2).I am storing this JWT token in the cookie.
Now my question is how do we store/display user details in the view continuously. For eg if we consider Facebook as restful , after a user logs in, client display user data such as profile image, profile link etc etc.
Since Rest Authentication just retrieves the data, with credentials sent in each request.
How are these user related data retained in the client side. Is it like for each request, user data is fetched from the server and updated continuously in the view.
If yes how or if no then am I missing something.
I know this question might be nonsense to experts, but any advice, suggestion or kickstarter information would be helpful for a novice like me.Are there any best practises for these?
Thanks in advance
Yes, you can fetch user data from server on every request but the right approach is to store it in JWT token as custom claims and on each request get the token from cookie, decode it and get the necessary details from those custom claims.
By the way, you can store user data in localStorage for frequent use.
Correct me if I'm wrong or someone can give me a guide about this. I'm working on an Ionic app with Laravel as a backend REST API.
A User can log in with credentials (email, password) or with Facebook.
Of course I wanna protect some states in the App as usual, and searching and reading in the web came across with JWT.
The thing is I'm little confused about how Facebook Oauth and JWT are working together.
So, here's what I'm trying to do:
If a user logs in with FB, get the id, nickname, email and creates a user with this information, also insert into a table this credentials from facebook so when it logs again check if the user already exists.
Then, this new user gets access to the app via JWT from the server, am I right??
Or how the auth token from facebook causes problem with the jwt token?? Or it will not??
Am I doing too much to resolve maybe a little problem?? Or is just the tip of the solution??
Thanx for your support.
The tokens shouldn't conflict. The process should be the "same" in both cases - the jwt is generated from an user instance/model.
How you create/get this instance is not important - from credentials, facebook token, cookie or what ever you like.
The jwt just includes an unique identifier - the id.
I have been reading about JWT.
But from what I read it is not an authentication mechanism but more like a crucial component in a Authentication mechanism.
I have currently implemented a solution which works, but it was just to try out JWT and see how it works. But what I am after now is how one should make use of it. From my experience of it its basically just an encryption mechanism that gives you a unique encrypted key. You are also able to put information inside of this token.
I am wanting to implement it in terms on a ASP.NET web api 2 to be consumed by a mobile application.
So step 1:
app => Server : Login (user, pasword)
Server => app : Login OK, heres your JWT
app => server : Get my profile (sends JWT with request)
Server then decrypts JWT and determines the requests Identity.
Now this is just my understanding of it, Look I could be on the totally wrong path.
Is the Ideal of JWT so that you dont have to authenticate on every request? I just authenticate the users credentials once (on the initial login) and there on after the server can simply use JWT and no have to lookup the users pw and user in the DB?
I just want to use the JWT to Identity who the user is. I will then authorize then after i have authenticated them. As I know there is a big confused with the new MVC and Authentication and Authorization.
So what my question comes down to.
How can I safely and effectively Implement a Authentication Mechanism Using JWT?
I don't want to just cough something up that seems to work and not have any Idea of the security implications. I am sure that there exists a source some where that has possibly designed a secure mechanism that would suit my requirements.
My requirements are:
Must only have to check db for users credentials once off per session? Due to the use of bcrypt using a lot of resources to compare passwords.
Must be able to identify the user from their request. (I.e who they are, userId will be sufficient) and preferably without accessing the DB as well
Should be as low overhead as possible, with regards to resources on the server side processing the request.
If an intruder had to copy a devices previous request, then he should not be able to access the real users data. (obviously)
Thanks
Your understanding of JWTs is good. But here are a couple corrections and some recommendations.
Authentication and Authorization
JWTs have nothing to do with authentication. Hitting your DB and hashing passwords only happens when you authenticate on creation of the JWT. This is orthogonal to JWTs and you can do that in any way you like. I personally like Membership Reboot, which also has a good example of using JWTs.
Theoretically, you could have the user enter a password once a year and have the JWT be valid that entire year. This most likely not the best solution, if the JWT gets stolen at any point the users resources would be compromised.
Encryption
Tokens can, but don't have to be encrypted. Encrypting your tokens will increase the complexity of your system and amount of computation your server needs to read the JWTs. This might be important if you require that no one is able to read the token when it is at rest.
Tokens are always cryptographically signed by the issuer to ensure their integrity. Meaning they cannot be tampered with by the user or a third party.
Claims
Your JWTs can contain any information you want. The users name, birthdate, email, etc. You do this with claims based authorization. You then just tell your provider to make a JWT with these claims from the Claims Principle. The following code is from that Membership Reboot example and it shows you how this is done.
public override Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
var svc = context.OwinContext.Environment.GetUserAccountService<UserAccount>();
UserAccount user;
if (svc.Authenticate("users", context.UserName, context.Password, out user))
{
var claims = user.GetAllClaims();
var id = new System.Security.Claims.ClaimsIdentity(claims, "MembershipReboot");
context.Validated(id);
}
return base.GrantResourceOwnerCredentials(context);
}
This allows you to control with precision whom is accessing your resources, all without hitting your processor intensive authentication service.
Implementation
A very easy way to implement a Token provider is to use Microsoft's OAuth Authorization Server in your WebAPI project. It give you the bare bones of what you need to make a OAuth server for your API.
You could also look into Thinktecture's Identity Server which would give you much easier control over users. For instance, you can easily implement refresh tokens with identity server where the user is authenticated once and then for a certain amount of time (maybe a month) they can continue getting short lived JWTs from the Identity Server. The refresh tokens are good because they can be revoked, whereas JWTs cannot. The downside of this solution is that you need to set up another server or two to host the Identity service.
To deal with your last point, that an intruder should not be able to copy the last request to get access to a resource, you must use SSL at a bare minimum. This will protect the token in transport.
If you are protecting something extremely sensitive, you should keep the token lifetime to a very short window of time. If you are protecting something less sensitive, you could make the lifetime longer. The longer the token if valid, the larger the window of time a attacker will have to impersonate the authenticated user if the user's machine is compromised.
I've written detailed blog post about configuring the OWIN Authorization server to issue signed JSON Web Tokens instead of default token. So the resource servers (Audience) can register with the Authorization server, and then they can use the JWT tokens issued by Token issuer party without the need to unify machineKey values between all parties. You can read the post JSON Web Token in ASP.NET Web API 2 using Owin
For the formal concept . The Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.
Let’s see the real life example
Imagine that your neighbor has asked you to feed his pets while he is away. In this example, you have the authorization to access the kitchen and open the cupboard storing the pet food. However, you can’t go into your neighbor’s bedroom as he did not explicitly permit you to do so. Even though you had the right to enter the house (authentication), your neighbor only allowed you access to certain areas (authorization).
For more detailed and for users who like more STEP BY STEP implementation on practical use of JSON Web Token in WEB API. This is must read post Secure WebAPI Using JSON WEB TOKEN
Updated to use: System.IdentityModel.Tokens.Jwt -Version 5.1.4