Background:
MySite.com - my website
ParentSite.com - website of a client
company (which will have OAUth
provider module on it)
MySite Module - a module which I have created which will be installed on ParentSite.com
and which will allow users of
ParentSite to be redirected to MySite (via
OAuth). I have full control over what
I do in this module. I will be displaying links that users will be clicking on and expecting to reach MySite and be fully logged-in.
My understanding of a standard OAuth setup:
Users go to a specific URL on MySite.com for OAuth login into ParentSite.com.
The MySite app retrieves an OAuth "request token" from the ParentSite.
The browser is redirected to the ParentSite.com site, asking to confirm that the MySite App is allowed to see the user's information.
The user confirms. (*)
The browser is redirected to the MySite.com, which now has an OAuth "access token" for the user.
The Client App sends a REST request back to ParentSite.com, using the OAuth access token from step 5 as authentication, requesting the user's identity information (e.g. ParentSite user ID, name, email address).
The ParentSite validates the OAuth access token and returns the user's information to the Client App.
My scenario is slightly different, the differences are:
A. The users are users of ParentSite.com and are at ParentSite.com and need to be seamlessly connected to MySite.com when they click on certain links on "MySite Module"
B. I would like the user-authorization step (step 3 and 4) to be automated, ie, no prompting of the user.
Q1: What do I have to do at "MySite Module" to enable all this? (detailed answer needed please!)
Q2: How can I automate step 3 and 4?
Ok, let me get this straight. Clicking on something in "parentsite" opens something on "mysite", "mysite" then tries to manipulate stuff at "parentsite" and therefore needs to be authorized to do so? If I am wrong, please disregard this answer.
I am also assuming that you have control over parentsite.com - otherwise I can not see a way for you to accomplish what you seem to need.
Part 1.
First of all, mysite needs a consumer key and secret.
Part 2.
Since calls to mysite are issued directly from parentsite, you can issue an access token directly within the parentsite service (you already know which user is logged in). So when accessing mysite.com - simply send it the access token and secret it needs.
Part 3.
Ok, so now mysite.com should have consumer key/secret and access key/secret and should be able to do stuff with parentsite.com.
Keep in mind that this really is outside the oAuth specification, but perfectly doable.
Related
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.
New to Oauth and had a general question. Is there a way to restrict who can log into your site with Oauth 2? Similar to AD groups or something so I could control who I want to be able to log in based on group or user name? I would like people to use google or facebook but only let certain people actually log in.
You can filter users in a code that handles the redirect_uri. If you use the Auth code grant, that will be some backend code and if you use the Implicit flow, it will be a code in a browser application. But the JavaScript security restrictions should have their equivalent somewhere at the backend too, since the JavaScript code can be altered by the browser user.
To be able to do that (to have info about an authenticated user), you should either request an ID token or an access token with a scope that authorizes you to get user info at the /userinfo endpoint.
I use OAuth2.0 of identityserver3 for SSO in company, I cannot understand how does the state parameter prevent the CSRF.
I have copied the attack flow as below:
1.Mallory visits some client's website and starts the process of authorizing that client to access some service provider using OAuth
2.The client asks the service provider for permission to request access on Mallory's behalf, which is granted
3.Mallory is redirected to the service provider's website, where she would normally enter her username/password in order to authorize access
4.Instead, Mallory traps/prevents this request and saves its URL(Callback Url)
5.Now, Mallory somehow gets Alice to visit that URL. If Alice is logged-in to the service provider with her own account, then her credentials will be used to issue an authorization code
6.The authorization code is exchanged for an access token
7.Now Mallory's account on the client is authorized to access Alice's account on the service provider
I can understand step 1 to step 4. But from step 5 I got some confusion. Accordding to my understanding, in step 5 Alice visit the Callback Url when she is logged-in, and then the server just use the authorization code to access the OAuth service provider to get an openid and access token in backend, and then Alice's browser just executing login with Mallory's account and access token.What is the relationship with Mallory's browser?
Could you explain it in detail please? Thank you for taking time to read my word!
I think steps 3 and 4 are not quite right. I've edited your example to show how I think the attack works.
1.Mallory visits some client's website (e.g. https://brilliantphotos.com) and starts the process of authorizing that client to access some service provider using OAuth (e.g. Acebook - as brilliantphotos.com allows its users to post pictures to their Acebook page)
2.brilliantphotos.com redirects Mallory's browser to Acebook's Authorisation Server requesting a redirect back to itself once auth is done.
3.Mallory is redirected to the Authorisation Server, where she enters her Acebook username/password in order to authorize access.
4.After successful login, Mallory traps/prevents the subsequent redirect request and saves its URL(Callback Url with an auth code related to Mallory) e.g.
https://brilliantphotos.com/exchangecodefortoken?code=malloryscode
5.Now, Mallory somehow gets Alice to visit that URL (maybe as a link on a forum post...) note that Alice may already be logged-in to brilliantphotos.com with her own account.
6.Alice clicks the link to brilliantphotos.com and the authorization code is exchanged for an access token (access to naughty Mallory's account). If Alice is logged in then brilliantphotos.com could conceivably associate Alice's account with the newly minted access token.
7.Now if Alice continues to use the brilliantphotos.com website, the client may inadvertently be posting pictures to Mallory's account on the service provider (Acebook).
If a state parameter was maintained by brilliantphotos.com then Mallory's state code would be bound to her browser but not Alice's. Therefore brilliantphotos.com would not be able to correlate the state code with Alice's browser session when Alice clicks on the malicious URL.
Besides iandayman's already great answer, you can also get some inspiration from this blog post, or at least you can take a look into its illustration.
PS: Credit goes to original blog author.
I have an application that currently integrates into my merchant account using my access token. Early discussion with neighborhood merchants indicates some positive interest. I want to integrate OAuth support so that I can try to get traction with those merchants.
Though https://docs.connect.squareup.com/api/connect/v1/#navsection-oauth has information, I seek some additional clarification.
(i) Access using https redirect-url is denied at Square Connect Authorize has an answer "By default the OAuth flow is disabled for applications which is why you are seeing the "Authorization not allowed" failure. If you wish to enable OAuth flow for your application then you need to contact Square." #SquareConnectSupport: I have sent an email to Developer#Square, please let me know what else do I do.
(ii) Here is how I think it will work - the OAuth integration (Please confirm)
User types in browser say "mysnow.com/square"
The Handler at "mysnow.com/square" allows user to type in an ID this ID is local to mysnow
Then the Handler at "mysnow.com/square" directs the merchant to https://connect.squareup.com/oauth2/authorize along with my application id, permissions and redirect url.
The handler then receives a notification code with AuthZ Code at the redirect URL previously provided.
Next the handler obtains the Access token (using the AuthZ code)
Finally, the handler then saves the ID, the AuthZ code , the relevant Access Token and the date/time stamp (when the token was obtained) as a tuple in a safe data store.
(iii) Using the Access Token
When there is need to access merchant data of given ID, then use the ID to get the Access Token. Use this Access Token to manage the permitted data (based on permission)
Renew the access token periodically.
(iv) For testing purposes, I create few test/dummy merchants? Or do you have dummy merchant accounts that I can use for testing.
You can authorize up to ten merchants through the OAuth flow without approval from Square, which should be enough to get your integration running and tested. If you would like to make it more broadly available, you will need to contact Square about getting the app in the Square App Marketplace.
That looks essentially correct. The best practice for OAuth is something like this:
Merchant visits your landing page (e.g. mysnow.com/square) and clicks an action to start using your square integration.
Merchant's browser is redirected to the OAuth page (https://squareup.com/oauth2/authorize?client_id=YOUR_CLIENT_ID&scope=LIST_OF_OAUTH_SCOPES_YOU_NEED)
Merchant authorizes your application to access their data and is redirected back to your site. In the URL is an authorization code
Your backend makes an API call to Square to exchange the authorization code for an access token. It then uses that access token to look up information about the merchant and pre-populate fields of your signup form (e.g. you can get name, email, etc)
With a partially populated signup form on your site, merchant is prompted to complete their registration with your service.
There isn't really a way to create "dummy" merchants, but you can sign up for multiple merchant accounts with the same identity information, as long as you use a different email for each one. If you have GMail, you can do "you+someword#gmail.com" and the mail will be redirected to "you#gmail.com", so you don't need to create a bunch of email accounts to have unique email addresses.
I've been using Twitter Basic Authentication where you simply need to enter login/password and that's enough to post tweets. But now since twitter has turned it off, I have to look into oauth. I do have experience with oauth but I always used the common way to do this - get request token, ask user to "approve app", exchanged request token to access token, then use access token. Unfortunately that's too complicated for my particular task and I really would love to keep oauth as simple as Basic Authentication was.
The reason for this is that I need to have oauth_token for one user only - admin. So I am looking for something like this: admin goes to twitter and registers app (I guess that can't be avoided), then accesses some twitter page and obtains access_token for this app, then takes key, secret and token and enters them as configs in the admin area. After this the site has the ability to post tweets to admin's profile.
I've been trying to find how to do this with no luck so far so before giving up I decided to confirm that this is not possible (or hopefully possible and I just missed something).
You have 2 options to simplify using a single user application:
If the user that you are going to be logged in as owns the OAuth application, you can login to dev.twitter.com as that user, drill down to the application, then click the 'My Access Token" button on the right. You can then just copy and paste the access token values into your application
Similar to #1, but slightly more laborious: develop a simple application whose sole purpose is to give you the access token for the user you wish to login as (or use a sample application somebody else has made). Then, again, copy and paste the values into your application.