I'm building a web app using Clojure and ClojureScript and I need it to have authentication based on a white-list of organization. For example, let's say I've added University1.edu to my white-list, and when a student from that university wants to login to my web app, they would be redirected to their own universities login system. After that I would just a confirmation of whether or not they successfully logged in there and maybe create a session, cookies, or or something for them.
Is that possible and if so, how can I implement that?
Some common ways to implement this authentication schemes are OAuth2 and OpenID, which are commonly used in websites were you can log in with your social / Twitter / Facebook / Google account.
Using OAuth for instance, you register your website in some developer portal (depending on the service that you'll use to authenticate) and obtain a token that that you'll use during the login flow and after logging on their portal, users are redirected back to your site.
In order for this to work, every organization (eg. University1) needs to be a provider of this authentication scheme, so that's something you'll need to research.
In Clojure there is a couple of options: the buddy library seems to be a popular choice, but you could also use some Java libraries through interop.
Related
I have a website were we are using Auth0 as Identity provider, now we are going to offer courses for our users, we want to integrate our site with the BrightSpace (desire2learn) LMS platform. The idea is to create the enrollment use case using their API in our site (create the user account), after that we want the user to have access to the LMS, avoiding the user to login again when passes from our site to the d2l platform site.
How should be the authentication flow to implement something like SSO in this case?
Basically, D2L Brightspace does support seamless login via an external redirect to your identify provider; however, the institution using Brightspace will need to work with their assigned D2L Implementation team in order to have SAML configured properly.
We have several apps Deployed on Google Apps Marketplace using OAuth 1.0 protocol. According expiration OAuth 1.0 in Google Platform we are trying to migrate all the apps to new OAuth version but we are facing some difficulties regarding background request to Google Admin SDK Directory API.
In our apps we need to request for Domain user accounts, groups and other stuff related Email Domain structure. Until OAuth 1.0 we have been doing this with 2-LO (Two-Legge OAuth) so basically once Admin gave us access we can impersonate request for domain using this mechanism.
After reading all Google Documentation about Google API, Oauth Mechanisms and stuff, and after trying some code test hypothesis too, we haven't figured out yet how can we managed the same concept with OAuth 2 because of the following:
Using Web Server Oauth 2 Strategy simply will not work because in that scenario we would be getting a Domain user Access to Admin SDK. If we keep their access/refresh token pair to later querying Admin SDK and the user is deleted because Domain change it Admin we will be disconnected from flow.
I supposed in that case the best choice was Service Account strategy. The problem with this scenario is the user has to manually configure access to the App in their Admin Console according to the Google's document domain-wide delegation authority (https://developers.google.com/+/domains/authentication/delegation#create_the_service_account_and_its_credentials). This is really awkward for us since we were managing all application installation interactively and we don't want to remove User Experience facilities.
Finally, my questions are:
Is there any way to do domain-delegation authority with OAuth 2 with no manual user configuration, full interactively?
Is there any way to do this without needing user email, which in fact is one of the parameters in Service Account Oauth2 Strategy?
Must we keep 2-LO Authentication for this scenario and do OAuth 2 only for installation Google Marketplace part?
Any comments or guide will be wellcome.
Best,
Certainly - in the latest update to the Google Apps Marketplace, the act of installing an App means the admin doesn't need to do an additional manual step.
You need a way to impersonate a user in a Service Account. Depending on how you implement your application, you might need to utilize the Directory API.
OAuth1 is going away eventually so I recommend you use OAuth2 throughout to simplify your code complexity.
We are designing a web service for an application that takes OpenID as an authentication option. The question came up how do we enable API access for this user at a later time?
For clarity here is an example:
1) user A visits the site and registers using Yahoo (or other) OpenID
2) at a later time we'd like to enable API access to backend synchronization apps that act on behalf of this user.
3) giving an app a key that can access all accounts everywhere is not an option for security reasons
What are examples of using patterns like that?
Standard OpenID requires a browser because it depends on being able to load a page from a foreign site to complete the signin process. Therefore it's not appropriate for server-to-server API use.
It is more common to use OAuth as an authentication mechanism for server-to-server APIs. While standard OAuth also requires a browser and a user-interactive flow to grant access to a new application, it results in a token that can then be used by the application to act on behalf of the user for user-unattended requests.
Facebook is possibly the most high-profile user of OAuth 2 for APIs, and its Login Architecture document describes the various login flows they support at a high level. The one titled "Server-side Login" is the conventional OAuth flow, while others are different approaches that support different use-cases like mobile app sign-in and access from client-side JavaScript embedded on other sites.
I am starting a new web project and I intend to make it API based; that is I want to build the API first, authenticated via OAuth, then build a website and possibly mobile app(s) that use the API to handle data. I also have my eye on opening up the API to the public.
Here is my issue; I am struggling to get my head around how to authenticate these 'official' apps, the ones made by me, including the main site.
In OAuth the client creates an account for each user then seeks access rights via the resource owner logging in at the main site. This obviously does not work for me because the main site and the client are the same place and it also implies my users should be creating two accounts just to use my website...
I believe twitter uses its own API to run twitter.com and I get the impression that this approach is becoming quite normal so there must be a standard approach.
I must be missing something, but what?
You are confusing the API (business logic) with the authenticaton of user identity (for example logging in), and the authorization of third party apps (OAuth).
It is correct that twitter.com uses their own API. But they don't use OAuth on their own site. When you're on twitter.com, their APIs are available to themselves over cookie authentication. To put it simply: you're logged in.
Once you move away from twitter.com you have to use OAuth. Now an application is using the API on behalf of a user.
To sum up. You don't specifically need OAuth for your "own" web client to use your own APIs. You need OAuth, or some other authorization mechanism, to publish your APIs and it will also come in handy for your own "official" apps.
There is really no need to distinguish your own official apps from third party apps. Not from a technological perspective anyway.
Host two versions of the "API". One mapped to the external domain api.yoursite.com and it OAuth-enabled to authenticate all requests. The other internal version is accessible only within your pool of servers, your official apps. Since only your official apps can access it in the first place, consider all requests to the internal API trusted.
If you want the same application to manage both external and internal calls, you can choose to
distinguish external and internal requests based on incoming IP addresses
implement your API to accept one of "VIP passes" or OAuth tokens for authentications. External apps use OAuth tokens to perform actions on behalf of certain users. Official apps use "VIP passes" to perform actions on behalf of any user.
Should I use oAuth, for example LinkedIn or Twitter, as my signin mechanism for my app? It seems that most apps just use oAuth to connect other services to it, but they make you set up your own user/password after you use oAuth (including StackOverflow), and I'm not really sure why this is. Would love some insight here. Thank you.
Why not use OpenId, to allow people to sign into your application, without having to type any specific login/password ?
Quoting the corresponding wikipedia entry :
OpenID is an open, decentralized
standard for authenticating users
which can be used for access control,
allowing users to log on to different
services with the same digital
identity where these services trust
the authentication body. OpenID
replaces the common log on process
that uses a login-name and a password,
...
BTW, that's exactly how one logs-in on stackoverflow ;-)
OAuth purpose is not authenticating your users with your site, is letting your users allow you (the oauth consumer) access to their protected resources in other sites (oauth providers) like LinkedIn, Twitter, Google APIs etc.
For authentication, you should use OpenId as others have pointed
Twitter provides a Sign in with Twitter flow that is OAuth but provides a faster redirect if it is an existing user of your service and they are already authenticated with Twitter.
http://apiwiki.twitter.com/Sign-in-with-Twitter
If you are building a Twitter centric application this makes a lot of since to use and you won't have to implement an entire alternate authentication method like OpenID.
Be careful if you let users authenticate with both Twitter and LinkedIn as users will inadvertently create two accounts and need them to be merged.
Facebook and Twitter both have the "Login with Facebook/Twitter" APIs to actually allow users to login without having to create an account for your website. Both of them will return you a valid session that may (or may not) expire. So you actually wouldn't have to ask users to decide on a username/password, as you can fetch both from the APIs (you can not get the users email address when using Twitter though)
So why add those functions to your website?
Users are in general more likely to hit the "Login with ..." button than going through the whole mail address authorization process and entering their name, etc...
Linkedin only has OAuth for usage to its API. It will also depend on what type of language you are writing your webapp in, they should have premade wrapper libraries you could tap on to.