I am relatively new to REST Framework for django. I was creating a simple app to login the users and I tried using Token Authentication. My concern is the tokens are created for each users and they are fixed (Do not change with time) and basically 1 user has 1 token mapped to him/her.
In case of a database breach or when the token is compromised wouldn't it be very easy for the hacker to just login my sending the authorization header?
I have some experience with django default session authentication which seems much more secure when comparing to the htoken auth of REST Framework. REST Frameworks implementation seems a little flawed or am I missing something?
Which one should I use in a production application?
(Note:- I am asking specifically for Rest Framework's default implementation of token auth not general token authentication.)
Related
Am I correct in the following thought process?
For a native app I'm building I want to implement a backend in Spring Boot.
This backend will be secured using Spring Security. Since I will manage and develop everything myself (the backend, the native app(s) and the web app for backend management) securing everything with JWT would be sufficient and implementing a full oauth server would be a bit overkill.
I have implemented the JWT token generation in my backend at this moment. On user sign in, the backend returns a json object containing some user details as well as an access token and a refresh token. The access token will be short lived, the refresh token will be long-lived (speaking about months of life time, maybe even indefinite unless revoked).
Is it correct that the refresh token could theoretically also be used as the access token? Or should I set some value/data in the refresh token that identifies it as a refresh token only (so can't be used to access resources, only to generate new access token)?
I was getting started with Spring Boot and Angular 7 and I came across user authentication.
Let's assume the following: I have a frontend with Angular 7 and a Backend with Spring Boot that offers API's that can be accessed via HTTP.
So I know that usually the frontend authenticates the user with e.g. JWT that stores all necessary information about the user that might be needed. But I came across the SecurityContextHoler of Spring Boot Security:
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
This allows me to simply access granted Authorities and so on. So I thought about the following:
Using JWT for the frontend grants the following advantages (as far as I know):
* Users can identify when using API's
* Users may be prevented from certain UI-Elements (based on roles stored in JWT)
* Modification prevention due to checksum (invalid token afterwards)
Now I could also add a check in my Controller in the Backend that checks the SecurityContextHolder for user permission (something like a Service that checks the current context permissions vs the needed permission and returns true/false). Wouldn't that be even more save, since it is in the backend (so in my inmagination everything that runs server-sided is always a little more save than what runs client-sided)?
I can store information in the frontend (like roles and a username) to use them for the UI-based-access prevention to still have the same advantages as JWT provides, but I do not have the "effort" of implementing the JWT creation.
But obviously it is not common to do it that way (at least I never saw it), so what is the advantage of the Tokenization?
They are not mutually exclusive. You would use what you call "Tokenized Authentication", like an oAuth2 Bearer token most likely in a JWT when the Authentication is performed by a separate system from your Spring Boot backend. For example, you may be using Okta, Keycloak, Google or Facebook to authenticate the user.
At a minimum, your Spring Boot backend stores the username extracted from the JWT in the Authentication. You can get Spring Boot to extract any roles in the token and add those to Authentication::grantedAuthorites. If your backend system, has it's own set of roles in addition to what's in the token, then the backend could implement a PrincipalExtractor to load a UserDetails object for this user from the database as the Principal and merge the roles in the token with those store in the local database.
You'll probably want to security certain methods in your backend with method security annotations like #PreAuthorize(), since you shouldn't trust the front end. The method security will check permissions, like hasRole("ADMIN") or hasPermission(object, 'READ') using the Principal object in SecurityContextHolder.getContext().getAuthentication();
In the end, the token assures the backend the user accessing it is who they say they are, i.e. Authentication, but does not necessarily tell the backend what they are Authorized to do. Yes, if you control the Authentication server you can include roles in the JWT, but roles don't usually provide as fine a grained control as is required.
Independent of what level of security you implement, the token is translated into an Authorization so you can use the Spring Security framework to manage access within your backend code.
There are 3 type of token in spring security OAuth2:
1. InMemory token Store
2.JWT token store
3.JDBC token store
So now you’re talking the JWT token store. The most powerful of JWT token store is prevent the authorization server load against to the database for checking such as role,token expired so it is related database load performance. Since all the information such as: role,username, token expire ,etc include in token itself. So the authorization server or other resource sever may using the public key to verify this token itself without invoke to data store.
Hope helpful! ☺️
I'm thinking to develop a full-fledged Identity System in Laravel 5 with Passport.
Following is my requirement:
I should have main identity management app like identity.mysite.com where all of my users are stored.
I have 2 other applications APP1, APP2.
When user request restricted resource on APP1, (s)he should get authenticated by identity.mysite.com
Once authenticated, let user access resources on APP1
Meantime, if user decided to access restricted resources on APP2, (s)he should not be asked to put credentials again.
Things I've tried:
simpleSAMLphp - SAML is an option which does these things for me. But it is not as mature as OneLogin and I'm not thinking to go in SaaS model at this stage unless it is necessity.
Laravel Passport - oAuth 2.0 seems tempting. I can even use, Passport Grant Tokens but I'm unsure on how reliable it is over SAML. Also, Laravel Passport is being widely used to authenticate API. Is it going to be useful while authenticating traditional session based apps? I haven't seen any example where the proper SSO is implemented with more than one application and laravel passport.
I know OAuth 2.0 is not an authentication protocol. Rather it uses something called Authorization but we probably can make it work to support Authentication protocol as mentioned here. Is it something, that Laravel passport supports?
This is what I call a resource oriented approach where all the clients(app1, app2...) want to know weather requesting user is authorized to access the resource or not...
Here we need to shift all the authenticating logic to oauth and make all our requesting apps dependent on OAuth. This way if user request app to access resources then if:
Token is present then app will request oauth server to validate given token and if found true then app will provide access to user.
If token is not present then you can solve it by asking for credential and app will transfer user data to oAuth server and validate it respond with the token.
As per my experience I use to implement this approach and I think Laravel Passport is an abstraction layer over top of your authenticating system. You can mold it however you need. There are few more enhancement and advancement can be done but this would work as a basic layer over top of your SSO.
You can achieve this with passport however you are right about the examples as there are not many or lacking on some steps.
You could to create a new middleware in App1 and App2 side that communicates with identity.mysite.com and gets the user data (token, scopes, etc, id) then it will verify if the token is valid.
On the passport server side you need an endpoint to return whether the token is valid or not and any additional info.
To avoid making too many requests to your passport server i would recommend to create a service that get the TTL of the access token and set it as the time on cache on App1 or App2 for the user data.
I have been following a tutorial to create a Spring SSO application which uses Facebook for authentication but creates its own access tokens to secure back-end resources.
The sample application creates a user on first login and stores the user's facebook token for further use (getting data from facebook later on).
My question is that how do I handle token expirations? When the facebook token expires, how do we setup spring security to refresh it? What about our application's token expiration?
You can find my sample project here.
The app in the tutorial only uses the token for authentication (i.e. it uses it once when the user logs in to get the user's personal details), so it's highly unlikely to expire in the time it is being used. Having said that, the OAuth2RestOperations instance that is used to carry out that single request is capable of refreshing the token on its own (if the provider sent it a refresh token and allows the access token to be refreshed by your client).
I'm considering using authenticated encrypted JWT tokens to authenticate / authorized access to an ASP.NET Web API application.
Based on what I've read so far, it seems to me like it is an option to generate JWT tokens from a token service and pass them to Web API via the http authorization header.
I have found some good code examples on implementing the JWT creation and consumption (Pro ASP.NET Web API Security by Badrinarayanan Lakshmiraghavan).
I'm trying to understand if I need a full OAuth implementation to support this, or if I can simply pass the tokens along in the auth header.
Assuming the tokens are properly encrypted and signed, is there any inherent security flaw in keeping things simple without having to use OAuth?
Trying to keep things as simple as possible for my needs without compromising security.
It is not that you must always OAuth when you use tokens. But given the fact that your application is a JavaScript app, you would be better off implementing a 3-legged authentication. Thinktecture identity server does support implicit grant. But if the client application getting access to the user credential is not a problem for you, your JavaScript app can get the user ID and password from the user and make a token request from a token issuer ensuring the user ID and password are not stored any where in JavaScript app (including DOM). This request for token can be a simple HTTP POST as well and it does not need to be anything related to OAuth. If your end user will not enter the credentials in the client application, OAuth implicit grant is the way. BTW, you don't need to encrypt JWT. TIS issues signed JWT and that will ensure token integrity. But if you are worried about the confidentiality, you can use HTTPS to both obtain the token as well as present the token.
It looks like you don't really need auth delegation as the one provided by OAuth. Isn't HMAC authentication enough for your scenario ?. With HMAC, you will not have to deal with JWT at all. This is an implementation I made for HMAC authentication for .NET
https://github.com/pcibraro/hawknet
Pablo.