Ok here is my question.
I understand the process of the OAuth protocol, however I have some confusion around it.
I'm trying to take advantage of DotNetOpenAuth.Here is where I don't get things.
Suppose a user (a new user), attempts to login to my website using Twitter.
The process goes like this (feel free to correct me if I'm wrong):
A request token is issued (if my ConsumerKey and ConsumerSecret are ok).
Then an authorization token is issued and the user is redirected to Twitter.
The user authorizes my application. And an access token is issued.
I get the current user's details and store them in the database (along with the access token).
So far, so good.
Now here is the confusing part. The user logs out. Then comes back and tries to authenticate with Twitter again. How do I determine his access token, If I can't get his identity before I have the access token ? I have him in the database, however I can't determine who he is, before he goes through the same steps all over again. I'm sure I'm missing something, and I'll appreciate it if you point it out. I'm aware of the IConsumerTokenManager, I tried reverse engineering the InMemoryTokenManager and see how it works, but it's still not clear.
Ah, the joys (ahem, lack thereof) of using an authorization protocol for authentication. I dislike OAuth for logging in. Grrr...
With that out of the way, let me clarify the flow a bit:
An "unauthorized" request token is issued (if your ConsumerKey and ConsumerSecret are ok).
The user authorizes your application, and is sent back to your application
Your request token is now "authorized" and DotNetOpenAuth exchanges it for an access token.
You use the access token to get the current user's details and store them in the database.
When later, an anonymous user visits your site and wants to log in, you start the flow all over. Only this time, since Twitter recognizes the user (after they log in if need be) Twitter will likely immediately redirect the user back to your application rather than ask the user to confirm the login. The request token will be authorized, you'll exchange it for an access token, and you'll use that to get the user's data. Oh! Now you see that the data matches an entry already in your database, and you welcome your visitor back.
Related
We have a project in development that uses Azure AD B2C exclusively to authenticate users. I am in the process of preparing some documentation on how the login flow works, tracing it in Fiddler.
For a user that correctly submits their username and password to the form rendered by login.microsoftonline.com, I understand they get an id_token in response, which they then present to our website to have their authentication validated and establish a session.
In Fiddler, I see the POST to ourtenant.onmicrosoft.com which includes the correct username and password. The response body is "{"status":"200"}" with a bunch of set-cookie headers (content omitted for brevity).
x-ms-cpim-slice
x-ms-cpim-dc
x-ms-cpim-cache
x-ms-cpim-trans
Following this, I see a GET to ourtenant.onmicrosoft.com which includes the above cookies, and ourtenant.onmicrosoft.com responds with a blob of HTML which contains the id_token in a hidden field.
My question is, in simple terms, how does Azure AD B2C correlate the correct username/password entry in the first POST to the id_token provided in response to the proceeding GET?
My rookie guess is that it uses the x-ms-cpim-cache cookie and, if so, I just want to understand what it stores and how robustly it's protected.
As far as the contract is concerned, cookies are internal to B2C. Since they are generated and consumed by B2C service, the internal structure can be changed anytime.
Passwords are validated in the same request in which the user provides them, and then discarded.
B2C keeps track of the progress a user has made in the authentication process using cookie(s). Such cookie(s) are encrypted. Beyond that, it does not help to state what's in these cookie(s). Today, it could be a GUID that allows B2C to store some state in a DB, tomorrow it could be some short-lived security tokens, etc.
I'm working on implementing ASP.NET C# Single Page Application + Web API with OWIN for Twitter.
So a quick summary:
The SPA client opens a popup window of the Web API that, via the OAuth/Owin-Twitter middleware, redirects the user to Twitter where he enters his username and password. Via back and forth of requests and responses, the Web API receives an authenticated access token from Twitter. The only reliable piece of data I have at this point is the access token.
So the question is:
Is there a way to verify an access token, that it was issued for such user and for such app/consumer?
After days of research, the only thing I have seen so far is:
GET account/verify_credentials
https://dev.twitter.com/rest/reference/get/account/verify_credentials
But thing is it requires a user context. I need a way that is workable with just an access token.
Any help would be greatly appreciated.
We have an audio blogging website which can be configured to publish links to the user's Facebook timeline whenever they make a new blog entry.
To do this, we have the user authorise our app when they set up the link to their Facebook account. We obtain the publish_stream, offline_access and manage_pages permissions (more on that later).
All the code is in C# but the principles apply to any language as it's the workings of the Facebook API we are concerned with. We're using OAuth 2 and the Graph API to achieve all of this.
So, we obtain an app access token using our app ID and secret and use that token to publish to the user's timeline, this works fine (because they have already authorised our app to do this). We can also query the Graph API and get their likes, friends and various other data.
NOW HERE IS THE PROBLEM:
Some of our users want to publish updates to their own timelime and also to the timelines of pages that they manage. In theory this is simple: you query the API for the pages that the user manages using this url: https://graph.facebook.com/{userid}/accounts?access_token={token}
The JSON returned from this call is said to contain the page IDs and the page access tokens for those pages. You then use the page access token to publish to the pages' timelines.
However, when we try to call this URL with the app access token we are getting an OAuthException 102 "A user access token is required to request this resource".
Note this is different to OAuthException 104 "An access token is required to request this resource" (which is what you'd get if you neglected to pass an access token), and also OAuthException 190 "Invalid OAuth access token signature" (which you would get if the access token was not a valid one).
So our access token is valid, but just not valid for this particular url. It seems therefore that we need a user access token and not an app access token for this particular feed (I am long past caring why this is the case, it just seems to be the way it is).
All the Facebook documentation on this subject (and I must have read all of it by now) leads to one place: http://developers.facebook.com/docs/authentication/server-side/, aka the "Server-Side Authentication Flow" page. This page describes how to get the elusive user access token by redirecting the user to the auth dialog and asking for the relevant permissions but we need to achieve this without interaction from the user and the user has already given our app all the permissions we need. All of this automated publishing happens server side in the post-processing of the audio so we cannot interact with the user at this stage anyway.
I don't get it. Why is it we can use the app access token to get almost any data we want from the user (well, whatever they have given us permission to get) but the /accounts data we need a different (user) access token for?
Can anyone shed any light on how we can get a user access token which will allow us to get the /accounts data for our users without any further interaction from the user?
So our access token is valid, but just not valid for this particular url. It seems therefore that we need a user access token and not an app access token for this particular feed
Due to the permissions per type of access token, you do need a valid user access token in this particular case. Read all about access tokens and types. That's just the way it is.
This page describes how to get the elusive user access token by redirecting the user to the auth dialog and asking for the relevant permissions but we need to achieve this without interaction from the user and the user has already given our app all the permissions we need.
If your user already has given his/her permissions, why are you struggling then? I suggest you persist the user access token. From this endpoint:
https://www.facebook.com/dialog/oauth?client_id=..&redirect_uri=..&state=..&scope=..&response_type=..&display=.."
you retrieve a code, like this:
YOUR_REDIRECT_URI?code=OAUTH_CODE_GENERATED_BY_FACEBOOK&state=YOUR_STATE_VALUE
Use this code to generate your user access token, as explained here:
https://graph.facebook.com/oauth/access_token?client_id=..&redirect_uri=..&client_secret=..&code=..
This will result in a response like:
access_token=USER_ACCESS_TOKEN&expires=NUMBER_OF_SECONDS_UNTIL_TOKEN_EXPIRES
There it is, your user access token. Persist it. As you can see it expires after the value indicated in the response. If you are using the new API, it should indicate 60 days (that brings me back to this: offline_access is deprecated and results in short-lived - valid for 2 hours - tokens), link. Whenever your user logs in to your app and uses the Facebook integration, the tokens gets refreshed to again, 60 days. This means, that IF your user should not login to your app and use it for 60 days, it will expire.
You can check whether the user access token is expired with:
https://graph.facebook.com/debug_token?input_token=INPUT_TOKEN&access_token=ACCESS_TOKEN
If that does: renew the user access token by using your app access token, it is well documented right over here. But I'm quoting this part:
Server-side Login
To obtain a fresh [user] access token in this case you must pass the user through the full server-side Login flow again. However, assuming the user has not de-authorized your app, when you redirect the user to the OAuth Dialog, they will not be prompted to reauthorize your app, and will be immediately redirected to the redirect_uri. This means that the re-authentication process can appear reasonably transparent to the user.
Bottom-line: there are no user access tokens that are valid for ever, the app access token however is. Persist your user access token and check whether it is still valid before performing API calls with it. A normal user should use your app within 60 days and should not just de-authorize your app for fun. Hence the use case in which the user should re-authorize is fairly rare, however, you need to expect it.
I am using twitterizer for posting tweets to a user's twitter account. It works fine but it is fully based on tokens (as you all know). This doesn't work in my case because Twitterizer redirects the user to the twitter page where the user logs and then using callbackurl the control is returned to our application.
My requirements are slightly different. I am storing user's twitter's account credentials in my database and then using those credentials I want to post the tweet.
Is this possible? So, in summary I don't want user to leave my site. They can configure their username and password in my application form and then I want to pick up those credentials and post a tweet.
Not sure about Twitterizer, but I believe you can register your app at twitter.com, do a one-time auth through OAuth, get and store the auth token, and use it permanently.
I can't speak from experience or authoritatively, but I believe storing their credentials in your DB is probably against Twitter's TOS.
See the OAuth FAQ for Twitter.
How long does an access token last?
We do not currently expire access tokens. Your access token will be invalid if a user explicitly rejects your application from their settings or if a Twitter admin suspends your application. If your application is suspended there will be a note on your application page saying that it has been suspended.
AFAIK, twitter has stopped allowing that kind of functionality now. The only way to connect is by making use of twitter OAuth.
I'm using C# to build some functionality for a website. They want to twitter a message to their account at the point when a new vacancy gets added to their website. I face the issue that when i try to do this using the OAuth token approach i have to grant access to the application everytime. I want this all to work automatically without the need for permission. Can i login the user and then just post a message or how do I approach this?
With OAuth you only need to get their permission once, and you can save the Access Token that Twitter returns to you and use it to act on behalf of the user as long as the user does not deny you permission to act on their behalf or the token hasn't expire. Twitter does not currently ever expire tokens see Twitter OAuth FAQ.
Just save the token along side the username in the database and use it to send post requests whenever you need to post to twitter.
Twitter puts it this way in this Transitioning from Basic Auth to OAuth Guide:
Prepare long-term storage for access tokens and secrets
Whatever your storage system may be, you'll need to begin storing an oauth_token and oauth_token_secret (collectively, an "access token") for each user of your application. The oauth_token_secret should be stored securely. Remember, you'll be accessing these values for every authenticated request your application makes to the Twitter API, so store them in a way that will scale to your user base. When you're using OAuth, you should no longer be storing passwords for any of your users.