I don't quite understand the api flow for twitter on a per-user basis for API transactions.
Here's my understanding of the user transaction flow:
1./ User signs into our web application.
2./ User authenticates with twitter and then the API sends the user back to a callback destination with a provided oauth_token and oauth_token_secret.
3./ We store the oauth information into a database.
4./ Now we have there access tokens and can send tweets on their behalf without needing them to log into the application again.
HOWEVER, this is not working correctly. When I try to supply the oauth token information, i'm getting invalid or expired token. OK so instead i supply the oauth token provided to me with the user oauth tokens given by the owner of the app and it works.
I think I'm mishandling the authentication process.
I'm reading here at the authentication docs.
Can anyone help me understand how i get my app to handle status updates on a per user level?
Thanks.
Ok. However I read for twitter there is no expiration
This is the actual transaction flow your application will take in order to use Twitter:
Register your application to Twitter to obtain an OAuth consumer_key and consumer_secret. This is for Twitter to identify the application that your user will authorize to access it's account.
When the user wishes to Tweet or access their Twitter resources through your app, The OAuth handshake process will redirect to Twitter, with the application's consumer_key so that the user will authenticate on Twitter directly. Once user authentication is successful, Twitter will provide your application with an access_token.
That's essentially what happens, except that Twitter uses OAuth 1 protocol so the handshake is more lengthier.
Access Tokens do expire for security reasons. It's like when you login to a system, the session is active for a period. When they do expire, you will have to request for an access token again.
I don't know if that explains your question.
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.
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'm implementing Facebook and Google SSO on my website using custom workflow (redirect urls, parsing on server side etc. - no javascript) and I got to the point I have access_token, token_type and expires_in and from Google also id_token and I am confused what to do next to authenticate the user.
I read a little about authorization vs authentication, and that Facebook and Google SSO is OAuth2 which provides authorization, but not authentication, from which I understand that this way my web application is authorized to do something on behalf of the user, but I cannot be sure the user is the one who I think he is? My main source is this: OAuth Authorization vs Authentication
So, my question is, what should I do to be able to can consider the user logged in.
Thank you
In your case google (and facebook) is authenticators. This services just tells your application that user who try to login to your system is the one who he wants to appear.
Assume you differentiate users by unique email.
Your application flow should be next:
The user try to login to application using google Application do all redirection google flow stuff and gives you tokens
Application need to store this tokens for future use
Application check if this user's email presented in database
If email is presented and google returns tokens (google authenticate your user successfully) you can login user in your app
If email isn't presented in database but google authenticate user successfully you can store this user (with email) to your database - sign it up - this is new user in your system
Same flow with Facebook. Surely you can extend this logic to be more your application specific.
SSO and OAuth are different. OAuth is authorization protocol.
You are dealing Google and Facebook oauth.
OAuth
In case of oauth, after successful authentication(google/facebook) you will get access token. You can use token for maintaining the user session.
With this token user is authorized, Now you should check whether the user is present in your database, if yes then authenticate the user and redirect to your application.
SSO
SSO is user authentication service. There are way to implementing SSO like kerberos SSO, ADFS SSO.
We should never use OAuth2 access token for authentication.
For details, please refer
https://oauth.net/articles/authentication/
The OpenIDConnect, built on top of OAuth2, can be used for authentication.
Google supports OpenIDConnect
https://developers.google.com/identity/protocols/OpenIDConnect
The basic idea is Google will issue the client app (your application) a ID Token after the user has login his Google account. You can then extract user information (e.g. email, unique user id) from this ID token and proceed your login flow.
I am trying to get an access token using my dropbox username and password.
I don't want to go and generate it from there site, as mentioned in there help documents.
No, Dropbox API apps should use the OAuth app authorization flow to get an access token for the user, so that the app doesn't have to directly handle the user's credentials. You can find more information on this process here:
https://www.dropbox.com/developers/reference/oauthguide
The method of generating it on the App Console that you mentioned only works for the owner of the app, but the OAuth app authorization flow can be used for any account.
Note that while this does require manual user intervention, it generally only needs to be done once per user. Once the app has an access token for a user, it can store and re-use the token for future API calls without further manual user intervention.
Dropbox API access tokens don't expire by themselves, though they can be manually revoked by the user.
I am developing a REST API. Currently I am trying to make it minimally secure. I am asking this question because most of the posts I found about this subject were quite old.
For authentication I found this schemes:
Basic authentication
AWS authentication protocol
OpenID
OpenID Connect
OAuth pseudo authentication
Basic Authentication and AWS authentication maintain the requests authenticated after a firts authentication because they keep sending signed requests.
I don't understand how the OpenID and OAuth authentication maintain a (second) request autehnticated? Do I need to check the access token with the OAuth/OpenID server per each request? How does this protects the REST API from receiving requests that have been altered?
Any other schemes that you recommend, advices or reading material about the subject are always welcome.
I'd talk about OAuth here
i) You create a web app and want to use google's OAuth API's.
ii) You register your app here and get credentials.
iii) Now, in the app you'd use Google's SDK to open the login page, enter your credentials and Google would verify it and send you access tokens and refresh tokens.
iv) You would make REST call to google's APIs with the access token and fetch user's data.
Now, coming to the question you asked -
An access token generally lives for 1 hour. Yes, any authenticated calls that you need to make to any of Google's API within one hour could be made with the same access token.
There is another type of token - the Refresh Token. At any time, your app can hit the provider's token exchange endpoint and exchange the refresh token for - refresh token + access token pair.
Now again, you have an access token that will help you for one hour and a refresh token that can be exchanged any time.
Refresh tokens live for as long as you want, till the time the user explicitly revokes permission to your app. (Tells Google that it doesn't not want you to access his resources!)
OAuth would make your REST API secure by ensuring that only authenticated and authorized clients can hit your API. But generally, OAuth is only used when there's a situation where a third party client needs access to a user's resource!