We have a project.
Nodejs RESTapi
React native mobile app
I followed a tutorial about Google oAuth signin / signup in Nodejs. There basically front end sends and access token to the back-end and the back-end verify that token with the Google, If that token is valid back-end generates a JWT token and pass to the front-end.
I think this follow will nicely working with the Single page applications,
but I don't know how this gonna be work with react native mobile apps. Because, according to the tutorial that access token get expired.
I have no idea what should I do after that token expired?
Usually you also get a refresh_token that it is used to renew the main access_token.
The access_token has a limited lifetime, but the refresh_token never expires unless you remove the authorization on Google's side. In that case you need to ask the client to login via Google's OAuth once again.
Related
I want to use azure AD as authentication.
If user who is in certain organization logged in from SPA, and give access token to backend, then I want to permit access from SPA.
So, I want to check if token passed from SPA is valid or not.
How can I do this?, Or Can I do this?
I want to build backend server with node.js app, and deploy backend app to app service or Azure Container Registry.
I think bearerStrategy would work.
Ref https://github.com/AzureAD/passport-azure-ad
BearerStrategy uses Bearer Token protocol to protect web resource/api.
It works in the following manner: User sends a request to the
protected web api which contains an access_token in either the
authorization header or body. Passport extracts and validates the
access_token, and propagates the claims in access_token to the verify
callback and let the framework finish the remaining authentication
procedure. On successful authentication, passport adds the user
information to req.user and passes it to the next middleware, which is
usually the business logic of the web resource/api. In case of error,
passport sends back an unauthorized response.
In the past, there was an ADAL version for node apps. I don't know if it's still valid or not, but here are useful links:
https://medium.com/#liangjunjiang/verify-and-decode-azure-activity-directory-token-bc72cf7010bc
https://learn.microsoft.com/en-us/azure/active-directory/develop/authentication-flows-app-scenarios
I have an iOS application that allows users to login with Facebook (via the Facebook Swift SDK). This returns the an access token for the user, which is specific to that app.
The user's facebook access token is passed to my NodeJS API where its authenticity needs to be checked. How can I do this? Basically, I need to check that Facebook has given the user this access token specifically for use with my app.
Once this is done, I will just use my API's standard JWT access and refresh tokens to authenticate future requests.
You can use the Debug Token endpoint within the facebook api, which provides if the token is still valid and which application the token is valid for.
I have a REST api and the authentication is done using jwt tokens. To make may api more secure (users and authentication mechanism) I would like to use firebase authentication. I would like to know can we use firebase as a authentication server for my REST APIs.
My understanding is that the client app will send the username and password to the firebase server and they will provide a token. Using that token client app will send an api call to our server. I need to integrate firebase admin SDK in my server and validate the token using admin SDK to get the data from my database.
Please correct me when I am wrong.
Also, i have a concern that how to manage refresh tokens to keep my app logged in.
Please help me to integrate this in the right way, and I am using nodejs/expressjs to create the APIs.
can we use firebase as a authentication server for my REST APIs.
Yes, it's one of the services they provide: https://firebase.google.com/products/auth/
My understanding is that the client app will send the username and password to the firebase server and they will provide a token.
Correct. The usual Firebase auth is done entirely client side.
But if there is a specific auth mechanism you need such as LDAP/AD or some other form of enterprise shenanigans, then you would need to create your own tokens that the client will use to authenticate: https://firebase.google.com/docs/auth/admin/create-custom-tokens
Using that token client app will send an api call to our server.
Correct. Once the client has successfully logged in and retrieved their ID tokens, you on the server side need to verify the ID token: https://firebase.google.com/docs/auth/admin/verify-id-tokens via middleware.
Also, i have a concern that how to manage refresh tokens to keep my app logged in.
You need not worry about that so long as the client uses the appropriate method to retrieve the ID token. For example, on the Web side the client would call: https://firebase.google.com/docs/reference/js/firebase.User#getIdToken which states (emphasis mine):
Returns the current token if it has not expired, otherwise this will refresh the token and return a new one.
As you can see, the client side Firebase SDK handles everything for you. There is no need for you on the server side to keep track of ID tokens, refresh tokens, or anything really. All you need to do is verify the token, that's it.
Please see my previous answer for more details on server side verification: Firebase authentication using NodeJS
I would like to give the users a possibility to login with some external oauth2 provider (facebook) in my app. The client's part is running on mobile device in a native app.
I am not sure which of the approaches below should I prefer ?
Should the client send the user's access token by facebook with each request ? At each request backend asks facebook to validate the access token. Based on the validation's result, backend performs authorization and return corresponding result to the client.
Should the backend ask facebook to validate the access token only at user logon, then issue its own access token, return the access token back to the client and client will use this access token at making requests to the server to avoid contacting facebook at each request ?
I have read some questions about how to implement the auth with facebook and most of the devs are using B, but I haven't seen any explanation why is it good/bad to use A ?
What I see as benefits of the solutions:
backend doesn't need to care about issuing, refreshing, validating access tokens since this is done only by facebook's authorization servers.
this solution seems to be more effective, since it does not require to connect to facebook at each request.
Security tokens issued by Facebook are signed with a digital signature. The API server only needs access to the public key to validate the signature. There's no need at all to contact Facebook after the user authenticates.
A reason to issue your own tokens after the user signed in with Facebook could be to add claims to the token. But obviously having your own authorization server comes at a cost. It's up to you to weigh the pros and cons.
If you do decide to have your own authorization server, make sure not to write your own! There are open source options like Thinktecture IdentityServer.
I will vote for option B and here is my explanation,
Your API must authorise the request every time with some auth token , which cannot be external provider token, in such case anyone with an access token (eg: other developers) of other provider can access your api, basically there is no auth here.
When your sever issue access token, it's easy to validate and when needed could be revoked easily (eg: on password reset)
While authenticating , your server has fully control over issuing access token , so the validation is made only once and doesn't have to do every time while calling the API.
I'm trying to build a mobile app that has a login functionality with an ASP.NET web api, and I need to implement the token based authentication,
what I need is, as a first time the user login using username and password, a new token will be generated with expire date along with a refresh token, I'm thinking of the refresh token because the user doesn't have to login every time the token expires,
the token is saved in the mobile device and in the database, so with each request, sends the token whether in the request header or with the posted data,
I don't exactly know how the token based authentication works in terms of sending the token encrypted or hashed to the user and processing the request in the server
Edit:
an attacker in the middle can just read the token and start sending requests to the server using the token. I mean he doesn't need to know what the token actually means.
I created a class that has these properties (UserID,Token, RefreshToken, ExpiryDate), but I read that it is not a good approach,
I'm using AES for encryption and SHA256 for hash
Thank you for you help,
Please see the following articles in order to understand how token based authentication works in ASP.NET Web API.
http://www.codeproject.com/Tips/821772/Claims-And-Token-Based-Authentication-ASP-NET-Web
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
Search OpenID and OpenID Connect specs, they will tell you exactly how the tokens should work in your case (non-confidential implicit client flow). You can add OpenID endpoints easily to your asp.net web api if you don't want to use an external openid server.