On my current project we planing to integrate Facebook for authentication. The site use different domains for i18n, sitenameineng.com sitenameinswe.se and so on.
Facebook only allows multiple domains with the same base URL and that's where the problems begin.
I could put up a new project for each language, but it feels incredibly unnecessary. What would be the best solution?
The only solution I can come up with is to create a new Facebook app for each language and then change the facebook app id and secret in my project depending on locale or is there a better solution?
If there is no better solution, how should I do to put app id and secret depending on locale?
Thanks
What about creating something like a proxy app which provides an API for all your domains to work with?
Say: proxy.sitename.com contains the SDK, authentication, database handling, and redirects to the proper website. You can then make requests to your proxy which, in turn, calls the Facebook API endpoints using the provided access token. Sure, this can result in slight perf hit, but this is probably the best way to solve this.
Considering the nature of your project, you might also want to consider: https://developers.facebook.com/docs/internationalization/
Related
My company is wanting to implement OpenID Connect via Oauth 2.0 across our client software, which comes in Windows, HTML5, Android, IOS, etc. Toward that end, we are trying to find a way of getting the login info back that will work across these platforms.
Our understanding was that a custom uri scheme (i.e., companyname://) was the recommended way of going forward, and we have verified on our end that that would work. However, we have yet to be able to find a provider that would support that configuration. So far OneLogin & Google are both locked to https:// (or http:// for dev), which leaves us something of a conundrum.
So essentially, my question is, were we misled about the custom uri scheme? If so, is there another method we can use that will allow our web & standalone apps to pick up the return info from whichever OpenID providers we go with? We want to keep it open as possible, so we're trying to avoid lock-in APIs and suchlike. Any advice would be appreciated. Thanks.
We do support the custom URI redirect. You'll need to select right type of client when creating a client id on Google developer console.
See the details here.
https://developers.google.com/identity/protocols/OAuth2InstalledApp
One way to support any provider is that you use a Web flow to redirect to a page on your site and then your website does a redirect to a custom scheme.
I'm writing an application that will be the backend for a react website. The website is to be used by our customers, but we will fully control the permissions of the user. We have decided to use Azure AD to secure requests, but will also be exposing the API for end users to use directly if desired.
My understanding is in Azure AD I will have to create an application that will allow web based implicit authentication (for the react site), as well as a native application that will allow a dameon based application to authenticate to the API.
This I believe means I will have two audience ids in my application.
I'm trying to get claims to include groups, and I can see if I edit the meta data of both applicaitons in azure AD to include "groupMembershipClaims": "SecurityGroup" I can get claims with the group IDs in, but no names.
I think I can also use appRoles to set roles the application uses, but I've yet to get that to come through as claims in the JWT, but I'm assuming it can be done, however I'd need to setup the roles on each applicaiton, then add the user twice which isn't really ideal. I also think that because my app is multi-teanated that external users could use this to set their own permissions, which isn't what I want to do.
Sorry I'm just totally lost and the documentation is beyond confusing given how frequently this appears to change!
TLDR: Do I need two applicaitons configured in azure ad, and if so whats the best way to set permissions (claims). Also is oAuth 2 the right choice here, or should I look at open id?
Right away I gotta fix one misunderstanding.
Daemon apps usually have to be registered as Web/API, i.e. publicClient: false.
That's because a native app can't have client secrets.
Of course the daemon can't run on a user's device then.
Since that's what a native app. An app that runs on a user's device.
This I believe means I will have two audience ids in my application.
You will have two applications, at least. If you want, the back-end and React front can share one app (with implicit flow enabled). And the daemon will need another registration.
I'm trying to get claims to include groups, and I can see if I edit the meta data of both applicaitons in azure AD to include "groupMembershipClaims": "SecurityGroup" I can get claims with the group IDs in, but no names.
Yes, ids are included only. If you need names, you go to Graph API to get them. But why do you need them? For display? Otherwise, you need to be using the ids to setup permissions. Names always change and then your code breaks.
I think I can also use appRoles to set roles the application uses, but I've yet to get that to come through as claims in the JWT, but I'm assuming it can be done, however I'd need to setup the roles on each applicaiton, then add the user twice which isn't really ideal. I also think that because my app is multi-teanated that external users could use this to set their own permissions, which isn't what I want to do.
Your thoughts for multi-tenant scenarios are correct. If you did want to implement these though, I made an article on it: https://joonasw.net/view/defining-permissions-and-roles-in-aad.
Why would you need to setup the roles in multiple apps though? Wouldn't they only apply in the web app?
If the native app is a daemon, there is no user.
Overall, I can see your problem. You have people from other orgs, who want access to your app, but you want to control their access rights.
Honestly, the best way might be to make the app single-tenant in some tenant which you control. Then invite the external users there as guests (there's an API for this). Then you can assign them roles by using groups or appRoles.
If I misunderstood something, drop a comment and I'll fix up my answer.
Azure AD is of course a powerful system, though I also find the OAuth aspects confusing since these aspects are very mixed up:
Standards Based OAuth 2.0 and Open Id Connect
Microsoft Vendor Specific Behaviour
ROLE RELATED ANSWERS
This is not an area I know much about - Juunas seems like a great guy to help you with this.
OAUTH STANDARDS AND AZURE
I struggled through this a while back for a tutorial based OAuth blog I'm writing. Maybe some of the stuff I learned and wrote up is useful to you.
AZURE SPA AND API CODE SAMPLE
My sample shows how to use the Implicit Flow in an SPA to log the user in via Azure AD, then how to validate received tokens in a custom API:
Code Sample
Write Up
Not sure how much of this is relevant to your use case, but I hope it helps a little on the tech side of things...
I'm building a standalone couchdb application. These are called couchapps. The idea is that the database itself is served on port 80 and returns HTML and works as the actual website. This is a very powerful idea and I'm entirely amazed by this new concept of having your code live inside your database.
But I'm having some issues with user registration. The one built into couchdb allows for cookies to be set and makes it really easy to plug it into your website. But there's several quite important things missing that my app requires in order to say that it has a "proper" user registration system.
There's no signup verification. No email is sent, no captcha is displayed. This means that anyone could spam your _users database and create as many new users as they please.
If a user forgets their password there's no facility to help them recover it.
Any idea how I could overcome these issues without doing any hardcore Erlang development at a lower level (not an Erlang guy)? It would also be great if anybody knew if I could be using OAuth to authenticate against Twitter or GitHub accounts and have that integrate seemlessly with how couchdb data is handled (inside validate_doc_update functions).
Thank you
While the built in user database can work, I would not recommend it for the workflow you describe. Here are some other options:
Browser ID
I would really recommend using BrowserID. IrisCouch has provided a plugin to couchdb here:
https://github.com/iriscouch/browserid_couchdb
This will take care of the normal registration workflow.
If you want to take it a step further and have your users "Fairly Anonymous", you can follow the example of this couchapp called "Mingle"
https://github.com/thedod/Mingle
Twitter Integration
Max Ogden's "DataCouch" project has a log in via twitter, although it is using some Node external processors to make it work. See here:
https://github.com/maxogden/datacouch/blob/master/processors/auth/twitterauth.js
Facebook integration
https://github.com/ocastalabs/CouchDB-Facebook-Authentication
OpenID
https://github.com/mcaprari/couchdb-openid
I dont think you can use the oauth purely with Couch, as this post suggests:
http://bennolan.com/2011/01/11/couchdb-oath.html
so the closest you will get there is following what Datacouch has done.
Hope these suggestions help.
I'm working on an appengine app which uses OAuth. Naturally, I'm dealing with multiple versions of the app simultaneously - a local version for development, a staging version and a deployment version.
To work with these, I need three separate sets of OAuth consumer keys/secrets as the callback on authentication is defined on the provider's site.
I was wondering if there are ways for providers to provide multiple keys/secrets for a given app - this would seem to make more sense than setting up a new app each time. (Of course, it requires the provider to implement this, but it seems a natural thing to implement and I haven't seen it).
More generally, what standard approaches are used to deal with this - my guess is register multiple apps and have logic in the app to determine if it's in development mode, staging or deployment. Any thoughts welcome.
I find this to be one of the most annoying parts of being an OAuth API client developer. There is no reason why providers should not allow developers to register redirection (callback) URIs for testing.
The standard approach I've seen is to allow you to whitelist one or more domains for callback / redirection. Facebook has some crazy setup where they let you "register" multiple domains by using different domains for the various links in the application profile. I did not have much luck with that. Twitter is one of the better implementation for that, letting you register multiple domains.
In OAuth 2.0 (draft 18 or newer), this topic gets much better treatment. Registration of the full URI is recommended, with the ability to register multiple callbacks and select the one you want to you dynamically at request time.
The main aspect to consider is how you want to handle permissions with a staging setup? Do you want to be able to reuse existing approvals or want to keep those separate? Also, if the API provides special client-only calls (such as client storage or management tools), do you want the stage version to share it or keep its own (so that testing will not mess up production).
At the end, providers should provide a complete development environment and that includes testing facilities for API clients. Most don't.
From an API provider's perspective your app is simply an app using the APIs. Usually there is no such thing as a "staging" API, which does not deal with live production data. Whatever it is you are testing, you are testing it on live data right?
If you are able to register several different applications with for example different callbacks then I think your problem is pretty much solved. My view is that it should be the consumer's responsibility to keep these things separated.
I'm building some applications using rails.
All apps using restful auth plugin for User base and declarative authorization plugin for authorization rules.
But I need to merge all site's User accounts to one User base for providing login for all sites.
I.e like 37signals working on. Here is their work ;
http://37signals.com/accounts
How can I archieve this, any suggestions are welcome.
Thanks
A.Karr
From studying how 37signals was doing stuff - I think they're using RubyCAS http://github.com/gunark/rubycas-server
It's perfect for single sign-on, single sign-off and other related stuff - when you have multiple independent applications. Also, because CAS is a generic protocol, it exists for non-ruby/rails applications too. SO you can integrate legacy systems or client applications in Java etc.
I started building a set of how-tos on the subject here:
http://rubyglasses.blogspot.com/2009/12/rails-single-sign-on-with-rubycas.html
Have you thought about using open id?
If all your apps run on the same domain you shouldn't have any problems accessing the authentication cookie in all the apps, but you'll need to store the authentication state somewhere where all the applications can access it.