Greetings!
Say I have fleet of mobile devices that are the consumers in a three-legged OAuth. The user authorizes each device, but then hands them over to other people. I would like to have these people then need an additional password to interact with the mobile device's protected resources.
Is there a standard, best practices way to do this? Could I use another, layered 2-legged OAuth, or should I do something else?
--Edit--
P.S. Since I posted this I discovered Twitter's "4-legged OAuth" for things like TwitPic, using a "delegator" this is a step towards answering my question, as it appears that OAuth can, in principle, be n-legged.
Are there other 4-legged and/or n-legged OAuth implementations floating around I can read over?
Thanks again,
Related
I am creating a new React SPA. Users of a legacy app need be able to use the new app without re-authenticating. So I need to support SSO.
It's important to note that it is also required that users of other (currently unspecified) apps should also be able to use the new app without re-authenticating, so whatever approach I take needs to be sufficiently decoupled to potentially allow this.
The legacy app supports authentication via Shibboleth, the new app currently has no authentication method, but uses JWT for authorisation.
I'm wondering if anyone has any experience of such a scenario? It seems to me that I probably need to be create an OAuth2 authorisation server for the new app to talk to and I need to somehow bring Shibboleth into the mix for the authentication, maybe with the authorisation service acting as a Shibboleth Service Provider. Googling around hasn't revealed much useful info.
Is what I've described along the right lines? I know it's very high level and woolly, but I'm really not sure of the approach to take. Any advice, information or experience in this area would be gratefully received!
GOALS
It's a little bit of a subjective question, but the main goals are usually as follows:
Focus on building your UI and API security in a future facing manner
Also provide good Login Usability
Also deliver on non functional requirements such as availability / reliability
AUTHORIZATION SERVER
On the first point, the modern option is to integrate UIs and APIs with an Authorization Server - perhaps as in My Tutorial. Your architecture is then good, but the migration is not trivial.
FEDERATING TO SHIBBOLETH
The Authorization Server can then redirect to Shibboleth and talk SAML2.0 to achieve Single Sign On, as you suggest. It is a complex solution though, and may be a backwards step in some ways.
AVAILABILITY
This is usually a big concern, and most companies use a cloud provider such as Azure / AWS due to its high availability / low maintenance / low cost. Would this be a better option for you?
I'm trying to develop an open source solution which will be deployed on Raspberry Pi's or similar SBCs. The RPi part is only relevant insofar as it means all the code and app resources need to be publicly available.
The solution needs to read Twitter statuses, as close to real time as possible, and with as little interference from third parties as possible. I found Twitter's Streaming API, which is blazingly fast, and would be perfect for my application – except it requires OAuth. And as far as I can tell, the OAuth mechanism isn't well suited for deployment on users' machines, since it relies on a secret key which belongs to the application owner (the consumer secret).
I couldn't find any easy way around this – the only solutions I could think of are either handling request signing on a central server, or asking each user to create their own Twitter app account. And I find both solutions terribly distasteful.
Do you see any elegant way out?
It turns out this is indeed not currently feasible cleanly with any of Twitter's public APIs; not now, and not in the foreseeable future. Refreshingly, for once we do have proof for a negative: I also asked this on Twitter's own forum, and I was lucky enough to have my question kindly answered by Andy Piper, Global Lead Developer Advocate at Twitter. There you go.
Your app can open a web browser with Twitter's application authentication webpage loaded. When the user enters their credentials Twitter will return a code which they can copy/paste into your app. It's not particularly elegant. Here is a Python example of the workflow: https://github.com/geduldig/TwitterAPI/blob/master/examples/oauth_test.py
I am trying to understand in what scenarios I should be using oauth. From reading the spec, I understand that you are essentially delegating identification to a 3rd party.
So if we take the example stackoverflow's login page you get
Oauth2 is being used for google and facebook, how do I determine what stackoverflow is using (when entering username and password directly)? Would that also be oauth 2? If it is using oauth, how would I go about understanding which flow they use?
Your question is a little unclear but what I think you're asking is if SO or some other site uses oAuth for all their authentication schemes. They could. If they using oAuth with user password authentication when you authenticate, the response you get back should have an Authorization Token and a Refresh Token in it that you would then use to authenticate on each successive request. Hope this helps. oAuth isn't a technology it's a protocol on how to do authentication in a better way.
See what is the request URL when you click to log in with gmail...
https://accounts.google.com/ServiceLogin?passive=1209600&continue=https://accounts.google.com/o/oauth2/auth?client_id%3D717762328687-p17pldm5fteklla3nplbss3ai9slta0a.apps.googleusercontent.com%26scope%3Dprofile%2Bemail%26redirect_uri%3Dhttps://stackauth.com/auth/oauth2/google%26state%3D%257B%2522sid%2522:1,%2522st%2522:%2522e35d652c26ae7fad9b61f6176cc93f2eb9bbb240c32231bc95f8270176d7a5d5%2522,%2522ses%2522:%252291fdf487240d4fa38576f780ad448f55%2522%257D%26response_type%3Dcode%26from_login%3D1%26as%3D-8520e47ae71bbb4&oauth=1&sarp=1&scc=1#identifier
Does that auth2 means oauth 2 ? I think so
UPD: As I understand OAuth mechanism is supported by 3-rd part. SO could use their own oauth for direct enter, or standard auttentication. It is up to SO.
To keep it short and easy:
If you want to add authentication to your application and you want to leave some security heavilifting to big companies like Facebook, Google and Stackoverflow it is generally a good idea if you do not know precisely how to handle such a delicate task and/or you are not using a specific Auth tool / framework.
On the other hand, from the user perspective, the application will be far more user friendly (just one click authorization instead of a painful registration).
If you want a much more detailed technical explanation I suggest you to read this other Stackoverflow post:
OAuth 2.0: Benefits and use cases — why?
I've got a rails app I want to start enabling some iOS integration with. I have a basic authentication system built mostly from scratch with a little help from Sorcery.
My understanding is there's basically two options for mobile integration: HTTP Basic Auth or Token Auth. From what I've been able to find so far it looks like Token Authentication is the preferred method.
I am not familiar with what token authentication is or how it is supposed to work, and I have not really been able to find any decent guides on this, except for a few tutorials on how to use the relevant module in the Devise library.
So, my question is, what is the basic theory of Token Authentication, and what would a from-scratch token auth system in rails look like? I understand that sharing the code for the entire system might be overkill for an SO answer, but I would be very grateful if anyone can help me understand a basic schematic of how such a system is supposed to work. I'd also happily accept links to any good existing materials on how to do this from scratch, as the main problem is I haven't been able to find anything like that.
Thanks!
Devise and Authlogic have a nice Token Authentication solution. You can either use one of these gems or to implement your own check their source code for inspiration.
Below is my understanding of how token authentication works:
The user signs in using a username/password combination through a
post request.
You authenticate the user and generate a unique token and
store it in the db.
You send this token back to the iOS device.
The device stores this token in memory.
Any subsequent call to the api need this token passed in as an
additional param to auth the user.
For this process to be secure this token needs to have an expiration
date and the communication between the iOS device and the server
must be encrypted through SSL.
For convenience you can store the user credentials on the device
using the iOS keychain.
I hope this helps.
I think there are three difficulties here.
There are very few books focused on authentication technique
The key word "token authentication" is confusing to use in security/authentication field.
Rails related documentation tend to be "how to."
So, Googling won't reveal good resources for this purpose. I know this field well, but it's difficult, especially due to reason 2.
In my understanding, "token" here work as an authenticated identity in the system, and provide bridge between authentication system and authorization system. But to understand this, you must understand overall system.
Let me provide few pointer with regard to authentication technique books and some papers here.
Butler Lampson did many work related authentication, and some of the articles are very good material to understand authentication/authorization framework. that might be helpful. One of the example is Computer security in the real world(2004).
Book written for Public Key Infrastructure(PKI) might be helpful. there are several of such. Such as Understanding PKI: Concepts, Standards, and Deployment Considerations, 2nd edition
Hope this helps.
ember-auth has a nice tutorial for token authentication for rails with devise and ember. However, it could also be applied to sorcery or to a custom authentication system. I think this is the best approach to authentication for an ember.js App.
https://github.com/heartsentwined/ember-auth-rails-demo
Can you use oAuth to only authenticate like you can with Twitter?
If you check Google's docs at http://code.google.com/apis/accounts/docs/OAuth2.html you'll find that the scope (meaning, the service you're supposed to ask permission to) is a required field.
It may be a turn off for many users if you ask them to access their contact list when the most you really do is authenticate, so I rather stick with OpenID which is designed just to retrieve the UID.
So, the answer is really NO, unless you're planning on using an additional API with Google.
OAuth is an authorization protocol and can't be used for authentication only unless the provider defines a dummy scope which, in effect, authorizes you to access "nothing", or "basic user info" (name, e-mail, etc.).
AFAIK, Google provides no such "dummy" scope. However, they do implement OpenID for such authentication purposes, as the protocol is better suited for that task, anyways.
Yes you can there are many options it depens on your platform advice you to check
oauth.net
You can find there options for Java, .NET, Cold Fusion,PHP,etc.
There are many Frameworks that have OAuth capabilities, on Spring you can use this
Sounds like there is some plans afoot on this...
http://googlecode.blogspot.com/2011/03/making-auth-easier-oauth-20-for-google.html?showComment=1300267218233#c6336940633709651714
some chap:
"Can someone help by pointing to the documentation for the API of "just get basic information for a user"
other chap:
"The problem is, that you get a lot of different login mechanisms because Twitter is using OAuth 1.0 (Or am I wrong?), Facebook is using OAuth 2.0 and Google is using OpenID for login. Please correct me if I´m wrong. So basically I have the same question.
Will Google support login for basic user informations with OAuth 2.0 for Google APIs?"
google dude:
"Today we're supporting OpenID for login, but we've heard your pain about mess of different identity protocols on the web. Stay tuned :)"
Seems to me, as OAuth2 covers authentication and authorization, it would make sense to allow basic info and make it easy on the integrator using one method for all
I'm plumping for this possibility anyway, hopefully by the time I'm ready to put my app live it will be available from Google - Facebook has this anyway and in my case that's a big enough draw