My app allows users to have custom subdomains, as in user1.domain.com. I am integrating various oauth providers, all of which support the ability to authenticate via oauth with a subdomain of the registered application domain. Is there a way this can be done with Foursquare, or if not is there a specific reason subdomains are not allowed?
You should be able to specify whatever callback URL you'd like via https://foursquare.com/oauth
Related
My question is quite simple, if you want to integrate social media oauth 2.0 you have to add the callbacks to an application for that specific social media platform such as FB/LinkedIn. Afaik, there's no way to add these callbacks through an API of some sort, correct? Meaning that if I want to add say a 100 callback links to fb, I'd have to add them manually?
To my knowledge, you're correct; it would be a manual process. There are a few specifications that would allow a more programmatic control of this registration information, but the specific provider you wanted to use would have to support them or a custom approach and again I don't think Facebook does it. For reference purposes:
OAuth 2.0 Dynamic Client Registration Protocol
OAuth 2.0 Dynamic Client Registration Management Protocol
Another possibility would be to go through a mediator that integrates with the providers you need to support and that can act as a provider on his own and at the same time allows you to configure the redirects in a programmatic way.
Diclosure: I'm an Auth0 engineer.
An example of this, would be Auth0; it integrates with Facebook and LinkedIn, but then allows your custom application to talk directly with Auth0. The benefit is that you configure Facebook and LinkedIn integration once with a single redirect URL and then can use that configuration acroos multiple applications.
Since Auth0 exposes OAuth2/OIDC endpoints you would still talk the same protocols but could now leverage Auth0 Management API to perform programmatic administration of the OAuth2 client application registration information; including the dynamic registration of redirect URL's. If you use FB or LinkedIn purely from an authentication standpoint this is a real straightforward approach to achieve your requirements. If your required the access tokens from FB to then make calls to their API on behalf of the user, although still possible with Auth0, you have a bit of overhead as these tokens would not be automatically available to your custom applications.
I have a client that wants to integrate to my software with the intention to do the following:
- link their users to our platform and then access particular information (oauth first and then transmit data [REST])
- present links to the user to then directly access authenticated pages on our website (SSO?).
Is it possible to this via oauth? Or is an SSO (SAML) needed for the second part?
Your question requires some more description, but get your leads from below notes.
SSO does single sign on for set of applications. Typically for internal applications within a security domain.
SAML-SSO does remote user authentication, federate users between different security domains and does single sign on for the applications. Typically for external applications on different security domains can be single sign on.
OAUTH does remote user authentication at authentication server and authorize user or others to give permission to access resource on the resources server. This does not federate the user nor single sign on of applications (as you need in your case).
Hope this helps to understand what exactly you need or you could modify the question to get expected answer.
How to share authentication information across multiple rails apps
We use omniauth, devise gems to enable authentication across (facebook, twitter, salesforce, regular user, LDAP, Microsoft Active Directory). We have multiple rails apps and would like to re-use authentication + authorization (cancan) using SSO. How should we go about supporting this?
You can create an OAuth 2 provider with Doorkeeper, either setting it up on the app that currently handles authentication, or extract it as a separate app that only deals with authentication.
Then you can create your own OmniAuth strategy which you can use in all your apps.
How do we allow a second client to authenticate users and access our api authorized backend? Please correct any part of my understanding that is incorrect.
User authentication is register / login / logout portion of your app.
App authorization for an api is confirming your app has permission to access an api.
A user should be logged in to the app and the app should be authorized in order for the user to access the api.
It is important to keep user authentication separate from app authorization because different clients (apps) may access our services through our api. Accordingly different users may have different access rights.
Consider a simple web app. Rails with devise is used in the app (api client) for user authentication. The app then accesses the rails-api using doorkeeper for app authorization.
Consider then adding a simple mobile app. How would the mobile app access the same user authentication service? How would we allow mobile app access to our user authorization service?
Would we need to separate the user authentication service into its own api using a separate instance of doorkeeper to authorize the mobile app and web app before creating users and then after authenticating users again authorize the app plus logged in user to access the backend api?
I'm sure it should be easier than described. Any resources, books, videos also appreciated.
If I understood your question correctly, what you are a looking for is a Service Oriented Authentication. Basically, the authentication provider could use Devise + Doorkeeper. Then the consumers could use omniauth-oauth2.
A good tutorial on oauth2: https://www.youtube.com/watch?v=zTsyeMV-N0c
Rails specific implementation: https://www.youtube.com/watch?v=L1B_HpCW8bs
Cheers!
I have implemented Google oAuth on the site (example.com). Everything works fine except auth from subdomains on my site(I have a thousands of subdomains). When the user tries to authorize via subdomain, for example
fr.example.com
product1.example.com
product2.de.example.com
I receive an error from Google -
The redirect URI in the request did not match a registered redirect URI
How it could be solved ?
The other answers have already clarified that the cause of the troubles is that Google's OpenAuth doesn't support wild card sub domains. However, what you're asking is how can it be solved? Well, you have two choices, according to this email thread:
Provide a single OAuth2 handling endpoint for all subdomains. That is, you'd have a main domain and endpoint, via which you do authentication also for the sub domains. When done authenticating, you redirect back to the sub domain. There's supposedly an OpenAuth state parameter, in which you can encode the sub domain name. This is what I did, here's the code: https://github.com/debiki/debiki-server/blob/master/app/controllers/LoginWithOpenAuthController.scala
You can have each sub domain register independently with Google.
Which option you'll choose depends on which brand the Google users are asked to approve. The main domain, or a sub domain?
That's because Google's OAuth does not support wildcard subdomain matching. You can refer to more documentation here
The redirect URI must exactly match one of the values listed for this project in the Google Developers Console (including the http or https scheme, case, and trailing '/'). So it will not support sub domains if you don't add them in Developers Console.
That's because Google's OAuth does not support wildcard sub-domain matching .You can redirect the one static page of all sub-domain and after authenticate or get access token of OAuth then you return on your sub-domain page with access token.
In the Authorized JavaScript origins field, enter the origin for your app. You can enter multiple origins to allow for your app to run on different protocols, domains, or subdomains. You cannot use wildcards. In the example below, the second URL could be a production URL.
http://localhost:8080 or
https://myproductionurl.example.com
https://developers.google.com/identity/sign-in/web/server-side-flow