I have done a lot of research on this issue without any success.
The oauth system used by twitter assumes you have a single application that can store the auth key, my situation is different. I have an application sitting behind a firewall that can get the required tokens, however the callback cannot get through to the application due to firewall rules.
I have tried changing the firewall rules but the people in charge of the servers refuse to do so at any cost, they also refuse to allow the website any write access to the one and only shared point of the application - the database.
The public facing area of the website has no way of giving information back to the internal web admin area, it is a one way transaction:
webadmin -> firewall -> (rw) database (ro) -> firewall -> website -> firewall
I need to authorize webadmin to allow it to post to twitter.
I can get the temp auth key and can redirect to twitter, but the twitter callback with the final authorization key can only get to the public facing website (10 physical servers) which have no way of talking to the webadmin so I can never complete the cycle of oauth.
I have tried saving to files and copy/pasting the auth code across but for some reason it blocks any tweets made if the oauth key is copied in this manner.
I have gone grey and am now bald trying to get this simple change in place,
please help.
As long as the user adding the Twitter account can visit webadmin in a browser and webadmin stores some sort of temporary sessions so to know what user is currently visiting it you don't need to mess with firewalls and nothing from from Twitter or outside of your firewall needs to connect into your network.
The basics of how this works is is as follows: 1) User visits webadmin and has a request token generated. The request token is temporarily storred in a session. 2) The user is redirected to twitter.com with the public half of the request token where they authorize access. 3) The user gets redirected to webadmin which they can get to because they are they user within the firewall. 4) The request token can no be exchanged for an access token to be saved permanently and used to interact with the Twitter API as the user.
Twitter supports xAuth on special request, which doesn't require that kind of callback, and might just work with your firewall. You basically just have to make the case as to why you need to use xAuth instead of OAuth, and then you use a slightly different request structure.
Related
We have some web services, and an OAuth2 server that protects access to them.
I want our outside clients to be able to use these web services in their mobile apps. But in some cases, they want to maintain their own login/password database, and not require the user to authenticate separately to our web services. In that case the client has identifiers for users on our side that correspond to their own users (we sync these up outside of the OAuth process).
So, assuming the users have already established a session on the client's side, I want to be able to give them some kind of access token that will grant them access to the corresponding user on our side, without prompting them for a separate password. How can I do this?
One approach would be to require the clients to set up a proxy to our web services, protected by their own session. Their mobile apps would send requests to the proxy server instead of our web services directly. Their server could use the client-credentials grant to get an access token, and add it to any incoming requests before proxying them to our server.
Is there a better way? This seems kind of difficult for clients to implement, and you'd have to verify somehow that the incoming requests aren't trying to access data for a different user.
Is there any grant that would allow the client's server to request an access token on behalf of an individual user, without the user's interaction? Then maybe the token could be returned to the app, and the app could use it to access our web services directly. With the client-credentials grant, the token gives access to all users, so it's not safe to return to an individual user's app.
Access to user's resource without user login or consent is anti-oauth(doesn't matter if it is 1.0a or 2.0). Hence there is no grant_type to support this directly.
Also the proposal of proxy, may not be a good idea for 2 reason.
Security: That proxy will open a gaping hole acoross your systems,
that knowning a user's email, an attack can get all the data from
your system.
Maintanebility: How would you keep track of authorization that the
client credentials token had access to a certain email across
system? This may create unnecessary checkpoints in your application(s).
Now, to here is a proposed solution which may work without changing much of your application
Please note it will be good idea to enable 2 way mutual auth or some form of additional security for verification.
Let me know if this doesn't solve the problem.
I've a site which will hopefully use a third party service for logging in (through use of OAuth2 and OIDC). I understand 90% of the process involved but am failing to get what I see as the final step. I'll describe the steps as I see them here and maybe someone can help me fill in the gaps. In my set up the Resource Server and Authorisation servers are the same machine.
This is the login process as I envisage it.
User comes to my site (let's call it Site A) and clicks login
They're redirected to the authentication site (Site B) where they
input their username / password.
Assuming correct credentials they're then redirected back to Site A with an auth code.
Site A takes this auth code and in a back channel communicates with Site B
again asking to exchange the code for a token.
Site B provides an access token to Site A (not to the end user, to the server)
Site A then communicates with Site B again (Resource and Authentication servers are the same in this scenario) and gets the relevant user detail.
So the user is authenticated and we know what claims they have, however, what I don't get in the above scenario is how Site A knows who I (the end user) am.
I never logged in on Site A so presumably no cookie was set. Basically I've gone to the site, been redirected to another site, logged in there and then am redirected back to Site A but is there a cookie set at that last redirect to identify me?
I've read plenty about this online but haven't found a clear answer.
Also, am I correct in thinking that in authorization code flow that the access token never gets to the user but instead resides on the application server?
If you really want to know who the user is on SiteA, it has to be the user from SiteA's own user database. It makes sense if SiteA is not just a proxy for SiteB's API and has its own users, permissions and functionality.
To figure out who the user is on SiteA you will need to match all your SiteA's users with Auth Server's users.
Part 1. Import your existing users into Auth Server
If you control Auth Server, import all your current users into its user database. Every one of them will have Subject ID (Id on Auth Server side). Copy those IDs back to corresponding users in your SiteA's db: your SiteA's User table will have new column, for example:
userid, user_name, user_last_name, user_auth_id (new column)
if you can't import all your users, it gets complicated. The only way I can think of: you will have to log those users in twice - once into OIDC provider and once in SiteA and then associate SiteA's user with OIDC user.
Part 2. Matching the incoming user to the internal user in SiteA
In successful response from OIDC Server you will get ID Token back. It contains sub claim with Subject ID of the user. When you've got that, you will need to do a lookup in your internal DB and find a corresponding SiteA's user. If you did not find one, create a new user at SiteA (if all existing users had been imported)
Once you know who the user is, log them in to SiteA like you would normally do (give them a cookie for example).
OpenID Connect auth servers provide the userinfo endpoint, which Site A can use for getting info about the user who authorized the access token (or the authorization code). For the auth provider (Site B) to be able to do it, it needs to keep association between a token and its user. So there is no cookie for this purpose.
You are correct about the auth code flow - the access token stays at the backend - there is no need to send it to the frontend / user.
To be able to pair the tokens kept at the SiteA backend with the consequent requests from the browser, you have few options:
You can use a backend session with cookies, which is very easy, because most backend frameworks have a built-in support for it. The cookie is sent automatically with each request and the tokens can be stored in a session object. This solution may be harder to scale - if you need a cluster.
You can create your own session implementation - either by using cookies or by some identifier expected on REST API as the Authorization HTTP header value. The backend session data can be kept in some distributed storage, such as Hazelcast or database. The session identifier can be in form of signed JWT, so you can keep user info in it.
I am writing an application which will connect to multiple email servers using OAuth. As part of initial connection establishment, user will be prompted to give access to application. After granting access, it will redirect to the url provided while registering the application in OAuth API.
Now i want to identify for which user the access token and refresh token belongs after redirect url comes to my application. I want to treat all requests happening in one user session as unique. Can someone help me.
I'm not 100% sure I followed your question, but my understanding is that you want to determine some of the information about the user that's just logged into your API client. You can get email addresses by requesting the https://www.googleapis.com/auth/userinfo.email scope and running a oauth2/userinfo GET request:
gapi.client.oauth2.userinfo.get().execute(function(resp,raw)...
Depending on which scopes you have access too, you will also get a display name and some other info. Best bet is just to console.log(resp) and pick out what you want to use.
I'm a front end developer helping a UX team develop the interface of a browser plugin.
The plugin is HTML/CSS/JS based and requires authentication. At the moment we have standard u/p fields in the wires, but the client is wondering if social sign-in is possible.
Since the plugin's interface is injected into each page that the user visits, it means that authentication requests can come from anywhere on the web.
I've read the basics of the oAuth spec, but I can't find an answer to this — it seems odd that oAuth would not require the requests come from a consistent location, but I don't really know what I'm talking about.
Is making oAuth requests from any random domain feasible?
requests come from a consistent location
A guy who can come up with tokens that are consistent with X's consumer key is assumed to be X. There is one place to demand the consumer's (your service) URL:
oauth_callback:
An absolute URL to which the Service Provider will redirect the User back when the Obtaining User Authorization step is completed. If
the Consumer is unable to receive callbacks or a callback URL has been
established via other means, the parameter value MUST be set to oob
(case sensitive), to indicate an out-of-band configuration.
But the redirection happens at the client's end. This URL can be set for each request. You dont even require a browser request: see the 'out of band' (OOB) stuff.
The workflow is called two-legged OAuth.
Twitter oAuth callbackUrl - localhost development
And that trouble is just for authentication. Once you have an access token for a user, you can act on his behalf from any device: a smartphone, a node in your cluster, your dev workstation etc.
x
i wonder how do desktop apps without any domain names use oauth? or is it not supposed to be used this way? if so what do i use? say for tumblr they have an authentication api so i will have to put the username and password in the url/query string?
i am thinking of using WPF/Adobe AIR. how does something like tweetdeck work?
I've been puzzled by the same question about lack of domain or app url, but it turns out redirection is not the only possible way to complete OAuth authentication process.
I.e., when webapp requests access it provides callback url: the one user will be redirected to when process is completed. That's how webapp know that everything's done.
But you can't redirect to application on user's machine. Thus, there's another way: upon successful authentication server presents special code to the user. Then user copies this code and provides it to application.
You can see both ways described in specification draft.
Also, here's an example of this authentication flow with twitter.
It looks like it may be possible, see googles docs on the subject:
https://developers.google.com/identity/protocols/oauth2/native-app
For a desktop app where a user needs to authenticate himself, you will usually want to use the Authorization code flow.
The approach goes roughly like this:
setup a temporary webserver that listens on the loopback interface
present the login page to the user (either in an embedded browser control or an external browser), with the URL of your temporary webserver as redirect_url
upon successful login, the user will be redirected to your temporary webserver and you can obtain the access code from the code query parameter
Using the access code, you can obtain a token and start making requests using it
Shutdown the temporary webserver
Please note that you will have to allow localhost as redirect URL in your identity provider, in ordrer for this approach to work.
For further details, please take a look at these sample apps from Google.
You should start by reading about getting started with OAuth. Eventually, even a desktop application will open a browser window to authenticate the user - TweetDeck and other Twitter clients do this, as you've probably noticed.
Tumblr, in your example, doesn't use OAuth but rather basic authentication that is being performed via simple HTTP web requests.
Twitter doesn't want users entering their credentials into your application. So at some point the desktop app will need to open a browser window through which Twitter can authenticate their users and return an access token representing the user. From that point the desktop app can use the access token to represent the user in all subsequent API calls to Twitter.
In a desktop environment you have another way to get the token, the browser open url itself.
the OAuth2 server will redirect the users browser to the Redirect URL with the token as a query parameter, so if you control the browser used, you can read the the token directly from the url that the user was redirected to.
Graphical libraries like GKT+ have integrated options to create mini browsers that the user can use to authenticate, and it automatically return the token to the app, but other options are possible, like reading Firefox url for example.