I am developing REST API Server in Node.js and it is almost Ready. Now I am trying to implement Authentication to API server. I decided to use OAuth2 for this. I think I will be Using grant type password, as most of the Apps that will use my service will be under my control.
There are some modules available https://github.com/jaredhanson/oauth2orize, I am confused on storing access token for the authorised users and mantaining sessions. As this is REST server do i need to mantain the Session, Or should i just store active tokens and related users to db and check for each request if they are valid or not?
Related
I am currently implementing a API project using express-js.
There are multiple clients for the API. This includes a front-end web app and some backend services.
I am looking at using a normal session based management for authentication using express-session.
I am preferring this over jwt since session based + secure cookies is easier for many use cases which I would need need
Ability to revoke user access from server side
Allow only single active web session for a user
I am sure I can maintain a separate persistance table with userid + refresh_token + access_token to achieve the above.
Its just that session based gives me these in straightforward.
Now when it comes to my daemon services, I would still like them to go via API route. This will be more like Client Credentials Flow.
Since these are non-http clients, cookies will not be supported.
I am not sure how my app can API's continue to support both of them ?
The only option I have now based on readings on various blog sources is to use JWT in the cookies for the web front end and using JWT as bearer in header.
This means that
I will need to implement all the security mechanisms like token black-listing, regenerating refresh_token etc.
I will potentially lose out on main benefit of JWT of statelessness.
What are the options I have to ensure that my API layer can support both front-end web apps like react/angular and other micro services
The standard solution here is to use an API gateway:
APIs receive JWT access tokens regardless of the client, and validate them on every request
Browser clients have their own routes to APIs, and send cookies that contain or reference tokens
Mobile clients call API directly, but with opaque access tokens
APIs call each other inside the cluster using JWTs, typically by forwarding the original token from the web or mobile client
The API gateway can perform translation where required. Here are a couple of related articles:
Phantom Token Pattern
Token Handler Pattern
Done well, all of this should provide a good separation of concerns and keep application code simple.
I'm trying to create an API for our app using Express.js endpoints that connect to our Firebase Cloud Firestore database. A main component of responding with the requested information securely is authentication, and we want to be able to make it as straight forward to the users as possible. For example, by them simply sending an API secret key on their requests.
My issue is that all of the authentication mechanisms that Firebase seem to provide require that the client is authenticated with the Firebase SDK, which would be uncomfortable for us to ask users to install.
In short, is there any way that they can either create a firebase token without the SDK or for us to authenticate them securely with an API key on our end? Note that the connection to our API would only be done through our user's back ends, never front end clients.
Thanks!
See:
https://firebase.google.com/docs/auth/admin/create-custom-tokens
Firebase gives you complete control over authentication by allowing you to authenticate users or devices using secure JSON Web Tokens (JWTs). You generate these tokens on your server, pass them back to a client device, and then use them to authenticate via the signInWithCustomToken() method.
To achieve this, you must create a server endpoint that accepts sign-in credentials—such as a username and password—and, if the credentials are valid, returns a custom JWT. The custom JWT returned from your server can then be used by a client device to authenticate with Firebase (iOS, Android, web). Once authenticated, this identity will be used when accessing other Firebase services, such as the Firebase Realtime Database and Cloud Storage. Furthermore, the contents of the JWT will be available in the auth object in your Firebase Realtime Database Security Rules and the request.auth object in your Cloud Storage Security Rules.
You can create a custom token with the Firebase Admin SDK, or you can use a third-party JWT library if your server is written in a language which Firebase does not natively support.
I'm working on adding google login to my web app. It's a RESTful app, so once a user is logged in, each individual request must be authenticated with a token.
Currently, I create my own tokens using JWT. I can add useful information to the token object to help with state management.
My question is: once I add google as an authentication provider, do I then need send every request to Google to be authenticated, rather than authenticating it on my own server? Do I then lose the ability to customize the content of the token?
With external authentication providers, is it normal to manage separate JWTs for calls to your RESTful API?
Normally, you'll have the login action use the third party to identify the user. Your internal code will probably create/store/fetch an app local user profile of some sort, and you'll create your JWT based on that. Further calls to your API bearing a valid token are then trusted to have already been authenticated and therefore need no further calls to the auth provider.
I have to develop a SSO system and I have to do it using IdentityServer4. I have gone through the documentation and examples but I have some doubts. To be honest I don't quite get it, but I am really new in Oauth2 and OpenId Connect.
We will have a bunch of clients (web apps), each of one of those will have their own Web APi. And we have to have a centraliced Login App for all of those. I think the example with the javascript client is the closes to the thing we want to achieve. Also, a user might have permission to access one client (app), but not another, so the IdentityServer must provide information about wich clients (apps), that particularly user can access.
So, These are the things I don Understand:
1.- In the documentation I can read there are two tokens, an Identity Token and Access token. But in the examples all I see are the access tokens. It seems to me that the access token is the one with all de info needed. am I wrong?
2.- Also, I have read about de Grant Types and I'am not quite sure wich one we must use. At first I thought to use the ResourceOwner password, because it requires the client, the secret, a user and a password, wich I assumed it could be the end user. I found this example http://sunilrav.com/post/How-to-Customize-Authentication-in-Identity-Server-4 were one could customise the class that validate the user and password. I thought that this could be the way to go but the documentation statesa about this grant type "...This is so called “non-interactive” authentication and is generally not recommended.". The javascript client example uses the implicit Grat type, wich the documentation states is for browser-based applications (our client apps will all be browser based using react).
3.- can my Login app be a Javascript (react) app? The example Quickstart is made in MVC.NET. This login app connects directly to de IS4 server without asking for a access token? (In the example the app is embebed in the IS4).
4.- Can I protect with IS4 a WEB API which is developed in .net framework (4.6.2) and not in .Net Core? I havent Found Any examples.
the documentatios I followed is the offcial. The examples (quickstart) are also there. (I can't post more than two links).
thank you very much for reading and for your help.
Identity Token and Access token
Identity token is the one that contains the identity of the user, that will tell the client app that what user it is. After successful login, user will be redirected to the client app with these tokens. Response will also have claims, such as permission scopes, name , email you can add custom claims as well.
Access token is used to access your protected web api resource. You have to send the access token with each request to access the api.
Grant Types
Grant types is basically how you want your client app to interact with the auth server. https://identityserver4.readthedocs.io/en/release/topics/grant_types.html
can my Login app be a Javascript (react) app? Your client app can be a javascript app but your auth server that is the identity server which will have the login/signup pages(and other login jazz) and account controllers should be you MVC app. As, everything is already done using MVC and Entity framework, why you want to re do everything.
Can I protect with IS4 a WEB API I am not sure about this one, but I dont see why you would not be able to do it.
This is a good answer for basic IdSrv flow!
UPDATE In my understanding, the answer to which Grant Type to use it depends on your client application requirement. If you want to use a Javascript client you can use Implicit Flow, but you won't be able to use refresh tokens and your access token is not 100% secured with the browser as client can access it.
If you want to open your web api to public then you can use client credentials flow. If you want to be more secure you should use Hybrid flow or HybridClient credential flow. ( again depends on the requirements ). with this you will be able to use refresh tokens and in this way your access token would be more secure.
I have a web application in node js that consumes an API for certain aspects of the content of the website e.g news. The API is written in node.js and points to a mongodb database.
I would like some advice as to the best authorization strategy for this type of requirement. I don't really need a user-name and password solution (I don't think). Some sort of static token that the web app can pass to the API so that only applications that have this token can browse the data returned by the API. I mainly want to stop just any old application consuming the API.
Here is best blog that can help you how to authenticate the REST Api in node js with the help of Basic HTTP Authentication, Oauth1 And Oauth2
https://stormpath.com/blog/secure-your-rest-api-right-way
Basically there are the three type of authentication that generally used
Basic Authentication
Oauth1.0a
Oauth2
Http Basic Authentication
More convenient, as you can easily expire or regenerate tokens
without affecting the user's account password.
If compromised, vulnerability limited to API, not the user's master
account
You can have multiple keys per account (e.g. users can have "test"
and "production" keys side by side.)
Oauth1
OAuth 1.0 requires client to send two security tokens for each API call, and use both to generate the signature. It requires the protected resources endpoints have access to the client credentials in order to validate the request.
Oauth2
OAuth 2.0 signatures are not required for the actual API calls once the token has been generated. It has only one security token.
Here describes the difference between OAuth 1.0 and 2.0 and how both.