I have a client who's requesting using oauth on their site so users can authenticate using their facebook or google credentials. I was wondering what information during the process is persistant so I can link them to their account records in my database.
My first instinct was to use the final token (the one used to actually request information from whatever site) but from my understanding those tokens can expire thus breaking my link. How can I identify who is who if their token expires?
If you're still unsure of what I mean, take stackoverflow as an example. I login to stackoverflow using my google credentials. How does stackoverflow associate my oauth login to my account information? Somethings has to persist.
I feel like I'm missing something glaringly obvious, but for some reason I can't connect the dots. Most likely due to my ignorance regarding oauth.
Any insight would be greatly appreciated.
EDIT: I just realized stackoverflow uses openID. Am I barking up the wrong tree? Can this be accomplished with oAuth?
It depends on what you're trying to accomplish. If the client wants to be able to manipulate the user's data on Facebook from their site then something like OAuth is going to be necessary.
If the client just wants to keep their user's from needing to create another user name and password then OpenID is probably the way to go.
If you use OAuth, when the token expires you have to go through the login process again and ask for another one. The timeout is a valuable security feature.
Related
I'm trying to get my head around OAuth from the context of having an API that I want to secure and a javascript based single page app made in Vue.js that will consume this API. I've been told that OAuth is the industry standard for this type of thing.
I want to let other clients like a mobile app also use the same API.
From what I can gather the right flow is Authorization Code Flow with Proof Key for Code Exchange (PKCE) https://oauth.net/2/pkce/
The bit I am confused over is how I seem to need to get users to approve access. For example you don't have Twitter saying "Would you like Twitter to use Twitter". If I was in the position of people using the account to create another account I wouldn't have any confusion but when the client is your own website what is supposed to happen?
I can sort of imagine that I could automatically approve the website or just bypass the part where the user approves but then I feel like I'm going off script. Then I think to myself, have I completely got the wrong end of the stick- is OAuth not designed for this?
If anyone can see where my ignorance is I'd be more than happy to be corrected!
Thanks!
OAuth and OpenID Connect enable you to authenticate users in many ways, for web and mobile clients. Each app implements a code flow and redirects to an authorization server (AS).
Each client is configured with an entry in the AS, and consent can be disabled when required. It is typically only enabled when personal assets are involved. Eg to grant a security code scanning service access to my GitHub repositories.
From asking around a bit and reading a bunch more found searching for "first party" providers: it is okay to just have the main website bypass the bit where they approve access and just send over the token.
I am using Gmail API to retrieve recent messages. And of course Gmail API requires OAuth2 Token to authenticate the requests. And repeat the task indefinitely every nth time.
However, I think that this is an impossible task. Because OAuth token expires. Though it has a refresh token, It will still need initial user intervention to start the task.
Does anyone experience the same problem? If so, how did you guys overcome it?
I'm kinda stuck on this matter. and would love to hear a solution.
I am using Gmail API to retrieve recent messages.
Your trying to access private user data you need the consent of the user to do that.
this is an impossible task. Because OAuth token expires.
Tokens expire this is intentional if they didn't and someone got your token they could use it for ever by having an expiration time on the token this limits how long a hacker would have access to your data.
Does anyone experience the same problem? If so, how did you guys overcome it?
These are things you should not be trying to over come these are things you should accept and try to understand the security they bring to your application.
I'm kinda stuck on this matter. and would love to hear a solution.
If this is a google workspace domain account, you could consider using a service account.
However if this is a standard google gmail user then you will need to use Oauth2 and request the consent of the user. If you have a refresh token you should not be having an issue you just need to authorize the user once and you will be able to request a new access token when ever you need.
I wanted to build a simple WP7 app to learn how to use Silverlight, so I thought I'd create a very simple yammer app. As a starter it would have two screens - Login (Username & Password) and Feed.
Yammer user OAuth for its authentication but I just dont get it! i appreciate you need to request a token to use the REST interfaces, but I dont want my users (even if its just me) to need anything other than their login credentials, as they would use on the website. In my head the token can be used in a similar manner as a forms auth token in asp.net
Am I missing something? But I cant see anything in the yammer documentation about logging in.
The process for OAuth is as follows
You do a token request to Yammer. If needed they will ask for yammer credentials and send a token back to a URL of your application
You must use that token to sign all your petitions.
You can't stop Yammer asking for credentials because that's the idea of OAuth. Yammer does not trust you and it's impossible for you to keep any user Yammer's credentials. That way they can't be stolen from your site. The more you can store is a temporal token.
There is a very good guide to using OAuth on hueniverse, which features an example workflow. It's not completely up to date with the latest version of the spec, although this probably doesn't matter too much for your purposes.
Goal:
Allow a user to authentication with Facebook into an iOS application which requires access to a protected web service that I'm running.
Assumptions:
There is a native authentication (and registration) system in place for those users that opt not to use Facebook for sign in.
Details:
Assume we want to offer the option for a user to sign in with Facebook without creating a separate account/credential for our system.
Because we support our own native auth mechanism (username and password) we have our own user IDs and issue an authentication token that is used for subsequent interactions after the initial credential validation.
I'm surprised that Facebook doesn't have best practices for this in their developer documentation. All the existing documentation is either assuming you are building FB auth into a website, or a standalone mobile app with no service that requires authentication.
Here's my initial thoughts on how this would be designed but want validation on whether it's correct.
Client pops the Facebook iOS Login
UI User signs in with Facebook credentials and gets access token
iOS App passes access token to our server
Our server talks to FB graph API using access token to (a) validate the token and (b) get the FB user ID for that access token.
e.g. Our server would call https://graph.facebook.com/me/?access_token=XYZ which would return profile info in a JSON object
Assuming it's valid, our server extracts the User ID from the JSON object and checks whether the user already has an account. If so, we issue our own auth ticket to client to use for that session. If user doesn't have an account, we create a new one with the Facebook User ID, assign our own unique UserID and issue our auth ticket.
Client then passes auth ticket back on subsequent interactions that need authentication.
This seems like the right approach to me but not sure if I'm missing something insanely basic and going down the wrong (complicated) path.
I just dealt with this myself, and here's the part that bit me:
In your step 5... It's possible for a user to register for an account with you entirely separate from their Facebook ID, right? Then some other time they log in with Facebook.... And you just created them a second account and lost their first one.
There needs to be a way to be logged in to your web service, then log in to facebook, and capture the association between the facebook ID and the local account.
Apart from that, your plan sounds solid.
Update: Facebook has added a doc outlining such a scenario HERE
Use https to transmit the auth token to your server, as stated by Facebook
Sharing of Access Tokens
Our Data Policies explicitly prohibit any sharing of an Access Token
for your app with any other app. However, we do allow developers to
share Tokens between a native implementation and a server
implementation of the same App (ie. using the same App ID) as long as
the transfer takes place using HTTPS.
One problem I can see with this strategy, is that somebody can give you an access token obtained for a different facebook app. As far as I know, there's no way to verify that the access token is for your application, so you'll just go on and use it.
It doesn't sound very harmful, though. Generally people/apps try to protect the access tokens, rather than sharing them.
One possible exploit of this would be, for somebody to create their own site or mobile app, obtain access tokens for their users and try to authenticate them, using your API. If this succeeds (the user is has a facebook account in your site), the malicious site will be able to use your API impersonating the user.
It's a bit of a long shot, but I think it could work.
Edit: It looks like there is a way to validate the access token after all. See the answer by #Daaniel on question Get application id from user access token (or verify the source application for a token).
your solution totally works.
Maybe an alternative: why not just get the email on the client from the initial social service request and send to your web service? The web service could just store the email, and maybe a social_provider as well. I understand that your web service will not be able to validate where the email came from, but isn't there a high-trust relationship between your web service and your client? If there is, seems like you can depend on the email coming from the right place. Someone please let me know what obvious thing I'm missing that makes the email-based approach silly...
Greetings!
I have some troubles enabling OAuth authentication for my web
application running on Ruby on Rails. I am using authlogic and
authlogic_oauth and that is, in the end, using OAuth gem and therefore
I decided to ask here. So shortly:
I succesfully "register" (i.e. obtain the first Access Token for the
user) but then, whenever I try to "login", I receive a differenct
access token for the same Google Account, the Authlogic-oauth plugin
fails to find the user and the login crashes. Maybe I don't understand
it right but is not the AT supposed to be the same every time. And can
it be a problem that I am accessing Google from http://localhost even
though the Customer keys are for different domain?
anyway, thanks for any reply ... I spend already 2 days with that
issue and debugging doesn't seems to lead me anywhere
Jakub
PS: I sent that question on Google Group oauth-ruby - sorry to anyone reading both channels
The AT is supposed to be different every time. OAuth is not an authentication protocol, it is an authorization delegation protocol. Try using OpenID instead: http://code.google.com/apis/accounts/docs/OpenID.html
Twitter does not give out different tokens which allows OAuth to be used as an authentication mechanism. LinkedIn doesn't do that meaning you may only use OAuth as an authorization protocol (which is what it was intended to do).
However, there is a useful API for pulling in data from LinkedIn. Of particular interest could be the Profile API.