I have a nextjs application that uses anormal (email/ password) authentication to my backend, if user successfully register I add him to a User Table and then when logged in we send JWT access token that is saved in a cookie in the client side. and whenever user submit a request to the backend we submit the token with it .
I would like to give my user the option to register and login with their google account for simplicity. how can I integrate both ? knowing that even if he uses oauth I need backend to save user and send Accesstoken to front end.
I found this answer I think it provides an excellent solution but it is a bit old . is this is the way I should go , or is there a better pattern.
Related
I am building an ASP.NET Core 6 Web API application for mobile clients (and maybe later SPA JS app). The application should have sign-in with Google option. I also want to add my own app's custom sign up and sign in options that would also be based on JWT authentication and not cookie.
I understand that for my custom sign in flow my app will generated JWT that will be sent to the client.
But I have few questions how that works when user signs-in with its Google account:
who's responsibility is to generate the JWT when user signs-in with its Google account? Is that responsibility of Google or mine application? I don't want Google to return JWT to the client in the cookie.
Then when client is authenticated with Google, and sends requests to my application, how can my application validate JWT token it gets?
When user signs in with Google for the first time, should I automatically register that user in my application (I am using Identity framework) by taking claim values (email) from the JWT? What is the general practice here?
I am trying to understand these processes and flows so sample code is not necessary (but I do welcome it).
Ad.1. Normally, in a larger system, you would have an authorization server (AS) that would handle user authentication and the issuance of tokens. Your clients would contact only the AS, and the AS will be able to provide the user with different forms of authentication: e.g., through your website's password or through Google. The AS is the single point of issuing tokens to your clients. It can issue tokens regardless of the authentication method used. So it then doesn't matter whether the user authenticated with Google or a password, the client will still get the same access token.
Ad.2. When the AS issues token to your client, then you don't have any problems validating that token. The client doesn't care if the user authenticated with Google or not, it's not relevant in this case.
If you decide to skip using an AS and let the client receive tokens directly from Google, then you can still verify them. An ID token is a JWT and can be easily validated with a JWT library using verification keys provided by Google. Access tokens returned by Google are opaque tokens (If I remember correctly), and you need to check whether Google exposes an endpoint to verify them.
Ad.3. That is the general practice. When the user authenticates with Google and you notice that you don't have that user's data in your system, then you take the information from Google's ID token and create a user entry in your system.
I have an existing system and want to utilize Auth0(still considering).
Context:
I have my own login screen, which is quite dynamic(white labeled) per client. So I dont want to use Auth0 login screen.
I have my own user and tenant database, so dont want to use Auth0 user database for now.
So the idea is to validate the user credentials after login on my backend and create access token to return to client side.
I want that access token to be validated by Auth0.
Questions:
1) Probably most important question. Should go with Auth0 or just stick with native jwt's
2) Is there a way I can create a valid access token in my backend which can be validated by Auth0.
Stack:
I am using vue.js as my front-end SPA.
I am using .net core as my backend.
Probably most important question. Should go with Auth0 or just stick with native jwt's
That is determined by whether you want to enable the online identity provider's features like Single Sign-On . If not , just keep using the current one since you don't need the Auth0 user database .
Is there a way I can create a valid access token in my backend which can be validated by Auth0.
Since your scenario is collect username and password in front-end application , and pass to backend .net application to validate credential and create token . You can implement the Resource Owner Password Grant in Auth0 to create access token for accessing resource which protected by Auth0, but as document shows :
You should use this flow only if the following apply:
The application is absolutely trusted with the user's credentials. For Single-Page Apps and Native/Mobile Apps, we recommend using web flows instead.
Using a redirect-based flow is not possible. If this is not the case and redirects are possible in your application, you should use the Authorization Code Flow instead.
So that it's not recommended in your scenario . If you need the features like SSO and want to use Auth0 , it is recommended to directly use Auth0 in vue application to manage your users and roles :
https://auth0.com/docs/quickstart/spa/vuejs/01-login
After login with Auth0 , you can map the user to local database user for specific management if needed .
Another way is using Client Credential flow . For this scenario, typical authentication schemes like username + password or social logins don't make sense. Instead, M2M apps use the Client Credentials Flow , your backend app will authenticates and authorizes the app rather than a user. It's not suitable if you want to acquire access token for specific user to access protected resource .
In auth0, a user authenticates themselves with auth0, then sends an access token to the app so that the app can make API calls. My question is: when the user authenticates themselves with auth0, what does auth0 send back to them? Is it an access token? If so, how does it differ from the access token that the user then sends to the app?
Thanks!
It gives them a token that you must verify with auth0 servers to make sure it's valid.
Auth0 sends back a few different types of tokens to the user.
The main ones are ID Token and Access token (as you have already mentioned).
Consider the following example assuming the setup of a web application & an API.
The user signs in to Auth0 through the web application and gets back the tokens mentioned above. The web application can then store the access token (for example in local storage) and attach this to requests to the API.
The API will see this token and can verify it has been issued by Auth0 and that the user has sent a valid access token. Then the API can know that the user is valid and can respond with privileged info.
To directly answer your question, the access token that the user gets back from Auth0 is the same one that it sends to the API. This will be sent around in jwt form which can be decoded when needed.
I have followed a few guides on adding authentication to my vue application (which has a net core api backend).
https://medium.com/dev-bits/a-guide-for-adding-jwt-token-based-authentication-to-your-single-page-nodejs-applications-c403f7cf04f4
and
http://jasonwatmore.com/post/2018/08/14/aspnet-core-21-jwt-authentication-tutorial-with-example-api
I'm a junior programmer with authentication so forgive me if my questions seem dumb.
These involve sending a username and password to my api login method and getting back a jwt token (is this an id_token or an access token?). I then send this token with every api request using the Bearer authorization. Some guides (eg microsoft net core docs) have this jwt token include role information.
Is this just a basic form of jwt authentication. Some things i have read about token authentication indicate that when i login i should get an id token which i then exchange for an api access token. These tutorials don't appear to do that - it looks like there is only one token and that it's used for api access and authentication.
Ideally i would like to implement oidc into my vue application but the many guides out there dont seem to address this.
The tutorials are talking about the JWT token based authentication , it will issue a JWT token to declare a user and their access permissions in the application.
When a user tries to log in to the application with their username and password, the server/api side will authenticate the user ,generate the token and send token back to client . Next time client could use token to access the server/API which eliminates the need for the app or system to remember or store the user’s credentials. You can involve user's basic profile information(not sensitive) and some custom claim in that token such as claim related to roles . Both client side and server side should check the specific role if you want to check the authorize part .
Id_token was added to the OIDC specification(OpenID Connect) as an optimization so the application can know the identity of the user, without having to make an additional network requests. It contains user profile information (like the user's name, email, and so forth) , and So if you are using OpenID Connect (Implicit Flow is suitable for SPA) to do the authentication and authorization , you will get id token which identity of the user , and access token which could be used to access the protected resource/API .
You are not using OpenID Connect , so no id token is involved in the scenario .
I am playing with JWT and expressJS to learn something new, and come up with the idea to make my little JWT provider to use for all my future personal projects.
The idea is quite simple, my provider will register with facebook and twitter API, and will use passport to authenticate with them. I will also store users credentials so I don't need to worry about that in my other projects (these project will hold their info about users but various data from socials/passwords etc.. will be in the provider).
I coded this little workflow:
I register the app in my provider with a callback url
Put a button (e.g. 'Login with Twitter') on my project, that links directly to my provider
when I accept the Twitter conditions, twitter callback calls my provider that pick the right user and redirect to my project.
I am stuck on this last point, I would love to pass to my project the JWT token to use for its next requests, but how do I pass to it?
Cannot set cookie because domains are different obviously, I am missing something? Did I follow the wrong way?
The authentication flow you describe is similar to OAuth2. I suggest to read the RFC 6749. It explain the technical details to implement it. You can also refer to OpenID Connect. It is an extension of OAuth2 using JWT
Basically you need to create an access token after a successful login and return a redirection to the callback url. The adapted flow to your context could be the following
App redirects user to central login form
The server prompts user for the credentials :It returns an HTML form with the supported authentication methods, that can include a connection with a third party authentication provider
After a successful authentication, the server creates an access token. It can be a JWT
The server returns a redirection to the provided callback url. It includes an authentication code
The app request the authentication server using the previous code and get an access token
The token can be used by app to access to a protected resource
In Oauth2, the access token it is just a random string, but you can use JWT perfectly.