Assume I already have a user data store that I am happy with (Usernames, Hashed passwords, etc ...) and all I want to add is the ability to issue and process JWT tokens and refresh tokens. What would be the minimal NuGet packages that would be needed?
I realize ASP Identity is a proven system, I would just like to figure out what is needed to issue OAuth 2.0 JWT tokens using Microsoft's NuGet packages. Assume that I already have the code to properly validate a username and password and I can determine validated or not validated.
Related
I keep seeing lots of tutorials for Rails API services where they just bring back session cookies and use lots of configuration of Devise. I'm not opposed to using Devise Token Auth but as far as I can tell, it doesn't support JWTs.
I want JWT support but also I want features like confirming/locking/unlocking accounts like Devise does. Anytime I see tutorials for JWT with silent refreshing capability (after an access token expired or is about to expire, the refresh token is used to get a new token) they are tutorials with Node.js as the back end. Devise JWT is a library that sits on top of Devise but requires a bunch of configuring of Devise and it doesn't support refresh tokens and the author of the library seems to have a weird philosophy about revoking JWTs (which defeats the purpose of JWTs in my opinion).
I feel like this should've been solved with some kind of modernized library for API only applications already or some kind of configuration with Devise or Devise Token Auth that supports access and refresh JWTs for the purpose of silent refresh.
Alternatively, is there a course that exists that goes through this with the intention of using React as the front end?
I've decided to roll my own solution. I've created a new gem called devise_jwt_auth that is essentially a JWT-based, access/silent refresh solution ported from Devise Token Auth. At this stage it isn't a mature solution but I welcome any contributors who would like to help. You can find the project here and its been published through rubygems.org so you can gem install devise_jwt_auth and use it.
You can try this library: rails_jwt_auth
It doesn't support refresh tokens but you can add this funcionality.
I am developing a WebAPI over my already existant MVC application, using the OAuth2 authorization system.
This API will allow my clients to request my users information. Currently, my users are stored in the Identity tables (ASPNetUsers). In my application, they are registering, logging in, etc... with the help of the Identity classes and methods.
The problem is here : I want to manage my API clients accounts, in an "Identity way", so I can authenticate them when they ask for Access Tokens. But I can't use the current users tables, as there is no common points between my clients and my users.
The perfect solution would be to have two Identity tables : one for my users, and one for my clients, but after my long-time searches, I figured it was not possible, or it would be a mess, at best.
I would not use ASP.NET Identity as a way to manage OAuth2 registered client applications. Even though some client applications (confidential) are indeed issued client credentials that's probably the only thing they share with a username/password user identity. It's a completely different thing and as such it should be managed and stored independently.
If you're thinking that this sounds like a lot of work, you're absolutely right. It isn't trivial to implement a custom username/password authentication that proves secure and implementing an OAuth2 authorization server is many times as complex.
If you really want/need to go that route then some mandatory reading:
The OAuth 2.0 Authorization Framework
OAuth 2.0 Threat Model and Security Considerations
JSON Web Token (JWT) (assuming you choose JWT as token format)
If you're still evaluating all your options I would also consider the possibility of delegating all the authentication/authorization work onto a third-party, Auth0 comes to mind, but I'm biased because I work there.
Currently, I think my understanding of OAuth and how it it is implemented in ASP.NET Web Api is flawed.
1) I keep seeing OAuth described as a server (i.e. the OAuth server). Is the OAuth implementation by a Microsoft a separate server with a different port or is it just referred to as a server even though it is self contained within the API project?
2) Is OWIN separate from OAuth or are the two linked such that they must be used together?
3) How does an OAuth v2 server keep track of tokens that have been revoked or have expired? Does the OAuth component have a database that keeps track of the tokens that it issues? If so, what type of database is it?
I have been reading the tutorials by Taiseer Joudeh from bitoftech.net but I think I am missing some of the basics.
Here are my responses:
You can implement the server as a stand alone authorization server or you can implement it together with the resource server. The Visual Studio template brings you both servers together, but you can separate them. Tutorials from Taiseer Joudeh will guide you very well, they did in my case.
OAuth 2.0 is an authorization framework, as said in its definition document. And OWIN stands for Open Web Interface for .NET. Both of them are different things, but Microsoft decided to do an implementation of OAuth 2.0 protocol using OWIN middlewares architecture. Then the easiest way to develop OAuth 2.0 servers in ASP.NET is using Microsoft.Owin.Security.* libraries implemented by Microsoft.
The OAuth 2.0 protocol does not talk about keeping track of expired or revoked tokens, you could implement if you want, but you only could do if the authorization and resource servers are both the same, and then you will need to access to database to check the token for each request, that it is not necessary. If the resource server is separated from the authorization server it has no direct access to the authorization server database. Normally you don't do that. The expiration check of the token is something that the Microsoft.Owin.Security.OAuth library makes for you. If a token received by the resource server has expired, the library responds with a 401 - Unauthorized response.
To make possible that the resource server can decrypt the token, you only need to set the same machine key in both servers' web.config file.
To avoid to have long lived access tokens you could set short access token timespan and implement refresh token. In this case, you could save refresh tokens in database and you can implement some method to revoke them.
Refresh tokens and its revokation are implemented in Taiseer Joudeh blog posts too.
I hope my explanations are clear and can help you. Please tell me if you have any other doubts.
I am using spring oauth2 for generating bearer tokens and validating them. I store tokens in database. I would like to know that is there any facility provided by spring oauth2 to cache the token as it is costly to go to db and fetch the token for validation when the servers are hit by 100tps.
I get that this is old but for the benefit of others.
Try not to store tokens anywhere unless you need the facility to revoke them. If you are committed to not storing them, that by default means you are (or should) be using JWT formatted tokens.
Spring, by default, includes user data in the bearer access JWT token that is produced.
Therefore your client / resource server that is a recipient of the JWT token has enough knowledge to automatically create an authentication object and manage access to resources.
I'd like to setup a central authentication / authorization server using Spring Security from where I could fetch JWT token which I could then use for accessing restricted resources on another Spring Security backed up REST server.
Here's my flow:
1) HTML JS / Mobile etc client authenticates on auth server to get the JWT token
2) Client sends this token in HTTP header to REST server to gain access to secured resources
I thought JWT would suite best for this scenario because it can contain all the relevant data and REST server could be fully stateless and simply decode the token to get all necessary data (role, clientid, email...) on REST server.
Is Oauth2 right choice for this and if so could someone kindly point me to right direction? If JWT isn't the right bet, I'm open to other solutions :) I should mention that in my case it's also possible to load client information from database also on REST server, but it should not be responsible for authenticating the user (meaning no username/password check, just the token decoding/validating...)
The Cloudfoundry UAA is an open source OAuth2 Identity Managemennt Solution (Apache 2) which issues JWT tokens. You could look at the way it is implemented, or just use it yourself, either as a server or just the JARs. It implements a bunch of existing strategies in Spring OAuth. It also optionally has its own user database, or you can implement your own. There are lots of options and extension points and many people using it in various ways (not all with Cloudfoundry) because it was designed to be generic.
Spring OAuth 2.0 also has support for JWT tokens as well, but it isn't released yet (the bulk of the implementation is drawn from the UAA).
However, since you say you don't mind opaque tokens (and a database loookup) you might prefer just to use the JDBC support in Spring OAuth 1.0. It was in use in Cloudfoundry for quite some time before we moved to JWT, so I can vouch for it in production.
As to whether OAuth2 is a good choice for your use case: you are in the best position to decide that. Nothing you said so far makes me think it would be a bad idea. Here's a presentation I did if it helps (you can probably find it on YouTube in the SpringSource channel if you like that sort of thing).
Alvaro Sánchez have developed a plugin with jwt compatibility. http://alvarosanchez.github.io/grails-spring-security-rest/1.5.0.RC4/docs/guide/tokenStorage.html#jwt
Install the current version in BuildConfig.groovy:
compile ":spring-security-rest:1.5.0.RC4", {
excludes: 'spring-security-core'
}
You only must to change the secret option in Config.groovy
grails.plugin.springsecurity.rest.token.storage.jwt.secret = 'YourSecretKey'
And set a chainMap to separate security managed with traditional mode from new rest stateless security.
grails.plugin.springsecurity.filterChain.chainMap = [
'/yourApi/**': 'JOINED_FILTERS,-exceptionTranslationFilter,-authenticationProcessingFilter,-securityContextPersistenceFilter,-rememberMeAuthenticationFilter', // Stateless chain
'/**': 'JOINED_FILTERS,-restTokenValidationFilter,-restExceptionTranslationFilter' // Traditional chain
]
You can to manage authorization and authentication within your application with the spring-security-core plugin.