There is an app that wants to authenticate with my users using oAuth2.
So they open a window, with the authorize URL, and parameters (such as redirect uri)
Like: https://my-website.com/api/authLauncherauthorize?redirect=SOME_URI
Now I have my own firebase-login, and when the user logs in, I get their access token from firebase. Which is what I want to respond with.
However, in oAuth2 guides/explanations like https://aaronparecki.com/oauth-2-simplified/ I see I am supposed to return an authorization code, and I don't understand where can I get that from?
What I can do, is generate a bullshit code, pair it in the DB to the access token, and then in the "token" request, send the correct access token. Is that what I am supposed to do?
Just to be clear, this is my first time writing an oAuth2 service myself.
OAuth is a system that provides authenticated access to resources. This resource can be for example a user page or editing rights to that user page. So your goal is to provide access to permissions to the right people.
When someone logs in, they get a token. Your part is to generate that token however you want, may it be some form of userdata into base64 or completely random. Take this token and link it against permissions, like viewing a page, editing it or even simpler things like viewing the email of a user.
OAuth2 tokens and/or permissions should be revokable without deleting a user. You should not use OAuth2 to identify someone.
If I am understanding your question correctly:
User visits some website
User wants to register or login using your websites OAuth2
You redirect back to the original page and send your generated token
The page can access content on your site with this token
Assuming you are the Host Site, given a User who wants to connect a 3rd party application, then the flow would be like this:
User lands on site - Clicks Login with Github
User is redirected to Github site where they login and click "Authorize"
Github redirects user back to your site /authorize with an auth token.
Your site then passes that token back to the 3rd party API (github in this case) in exchange for an access token and refresh token.
You can then pass that Authorization token to an API endpoint to get details about it. If the token expires, you can use the refresh token to get a new Auth token. Both Tokens should be stored in your database for your user.
However writing that all out I realize you are asking how do you generate the Authorization token, so I'm guessing you're actually the 3rd party API in this example. So you would want to generate an Authorization token using a random generator. Since you are using firebase, you'll probably wanna try out their token generator: https://github.com/firebase/firebase-token-generator-node
There's also some more up-to-date info here I believe: https://firebase.google.com/docs/auth/admin/#create_a_custom_token
And like you said, you would store that in a database associated with the user, and then when the Host Site sends that user's auth token to your server, you exchange it for the Authorization token (and refresh token if requested).
It's also worth reading through how google does it, because you'd be doing something similar: https://developers.google.com/identity/protocols/OAuth2UserAgent#validatetoken
JWT is another option of generating tokens: https://jwt.io/
Related
My current setup is the following:
Single Page Application with Vue
Rest Backend
The SPA has social login functionality. It uses the authorization code flow with PKCE to retrieve:
Access Token / Refresh Token
ID-Token
As it is an SPA, the information is stored in local storage and therefore not 100% secure.
But how do I use this information to actually authenticate against my rest backend? The rest backend actually contains the user data I need after all.
Originally, I thought I could just send my access token or id token to my backend and the backend uses this as proof that I'm the correct user.
Main problems I see:
Make sure the access token / id token is actually from my application (the SPA)
Be protected if the tokens are stolen / Minimize the impact of this
For the first problem, the client_id might help, which is embedded in the id-token. It is kind of public information (because it is an SPA) and there is no client_secret. But the redirect_uri is specific to my SPA. Is this enough protection?
If it is my backend could have a list of allowed client ids and providers and check if the client id of the token is one of them.
The second problem is the lifetime of the token. Access tokens are only valid for a short time period and refresh token should be rotated. So it's kind of okay to store these in local storage. But the id_token is valid for a longer time. What do to about this?
Is this in general the right track? Or is my approach completely wrong?
My system works as follows;
I have an ASP.Net RESTful API server, which contains a user database.
I also have a Xamarin.Forms application, with a registration and login page.
What I want is to have the ability to authenticate a login using a social IdP, and then, if that user has not been logged in before, register that user in my local database.
I have been reading up on how to implement OAuth 2.0 with OpenID Connect to authenticate my users with a social IdP, however, I cannot seem to wrap my head arround it. From what I've read, I shouldn't use an Access token for authentication, since that i what the ID token is for, however, I have also read that the only intended purpose for an ID token, is the client.
My problem then is, how can I make sure that calls made to my ASP.Net server, has been made by "real person", and how do I determine who makes the call?
Access token will be used determine whether the client application was authorized by a user to access a resource. The concept of ID token comes from OpenID Connect. Main purpose of the ID token is to authenticate the user to the client application (i.e. letting the client application know that the person who authorized the access is a valid person).
To do this, you have to validate the ID token. This can be done using third party libraries such as nimbusds or auth0. You can validate the signature of the token verify the integrity of the token and check the claims included in the token (by comparing them with expected values) to verify the user details. Also, you can add custom claims (any claim that is specific for your application/implementation) to the tokens through your identity provider so that you'll be able to validate those particular claims in order to verify the user.
I successfully authenticated my user with my firebase app in the browser. Now I want my custom backend to know that the user is authenticated.
How do I go about this? Can I tell the client to include the firebase JWT in every request to my backend, so that the backend knows the user is logged in? (This is necessary so that the backend will not redirect a logged-in user to the login page, for example.)
Background Research:
The firebase authentication docs explain how to get the firebase token, send it to your custom backend, and then do something on the backend with the user data. That's fine for an XHR request, where you can tell the browser to include the token as a header. I don't understand how to get the browser to include the token in a normal HTTP request to the server, like when the user opens a new tab and navigates to the admin panel at https://example.com/admin.
This is a related question, but I didn't understand the answer (or at least how I could apply it to my use case).
Here's how the good guys at jwt.io explain it:
Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema. The content of the header should look like the following:
Authorization: Bearer <token>
This is a stateless authentication mechanism as the user state is never saved in server memory. The server's protected routes will check for a valid JWT in the Authorization header, and if it's present, the user will be allowed to access protected resources.
In Webserver Grant Flow
After I obtain the Authorization Code from the authorization authority (after the user has authorized my access) how long is that code usually valid form?
The reason i am asking is, can my webserver store that code and use it in later sessions to retrieve a new access token without the need for the user to re-authenticate again? Should that be the flow?
FYI my goal is make requests from Adobe Analytics and Google Analytics on behalf of my customer. So i would want to ask my customer for authorization once until he revokes my access.
Speaking strictly of Google Oauth. There are three types of codes or tokens you should be aware of.
Authorization code
Access token
Refresh token
Authorization code is return when the user clicks accept to your application accessing their data. This code is used to exchange for an access token and a refresh token. This code can only be used once and is extremely short lived 10 minutes I believe.
Access tokens are used to access private user data. They are valid for approximately one hour.
Refresh tokens are used to gain a new access token when the access token has expired. For the most part refresh tokens do not expire however if it has not been used for six months it will no longer be valid and of course the user can always remove your access.
Answer: No storing the authentication code would be pointless. You will need to store the refresh token. make sure you are requesting offline access of your users.
I cant help you with adobe analytics however I suspect it is similar this is standard Oauth protocol we are talking about.
I am using oauth in my web application to access Twitter. My problem is i am not getting the token secret and moreover when i run my application it asks the user for authorization request. when the user click "allow', it does not go back to the called url. Infact it shows a blank untitled page with a url having oauth _token value and oauth_verifier value.
Can someone throw light on this.
Before you send users to twitter.com to authorized the app you need to save the request token secret. When the users clicks allow they will return to the callback url you specify. Once there you need to use the request token/secret to get an access token from twitter that will let you perform API requests as a user.
http://dev.twitter.com/doc/post/oauth/access_token