Context
I have a Node.js application that has a "complex" set of OAuth flows in order to make the UX simpler.
I have the usual login and registration flow where you may use an OAuth provider to authenticate. I don't require any special scope here, since OAuth is being used purely for authentication and the user has no reason to want to give me elevated access (say to private GitHub repositories), and might even think this is a shady thing to ask, so he goes away and never visits my product again. So, no scope for the pure authentication flow.
The application also has an import functionality where you can import a list of entities from an OAuth provider (say, GitHub repositories). By default, you aren't asked for any scope here either.
Clicking on the "Looking for your private repositories?" button authenticates you against GitHub again, asking for the repo scope. This is all fine and well.
The issue
Is that when the user tries to login again, or otherwise do anything that might authenticate them but doesn't explicitly request the repo scope, GitHub deems this an explicit downgrade request.
The issue is the user wouldn't want to downgrade during logins for no particular reason. Similarly, I don't want to ask for more permissions than I need during logins.
Leaving things in this state would be even worse than asking for repo at login, but that would be an extremely poor choice as well.
Potential Solutions
Besides the two non-solutions, the potential solutions I've come up with are:
Ask GitHub explicitly for unique access tokens based on the requested scope, store the tokens separately, and use them as needed afterwards
That'd be great, except it'd be way too stateful and I haven't found a way to do it anyways; they seem to give you a single token per application user, and I suspect this is how OAuth works, for the most part, but I'm hardly an expert on the matter.
Tell GitHub explicitly not to downgrade a token if it has more priviledge than what it's asking for.
This sounds to me that it should be the default behavior. Anyways, is there any way I can tell GitHub not to downgrade a token?
If not, is there any other way I can fix this without resorting to asking for the same scope across the entire application? This would partially defeat the purpose of scopes in the first place.
Also, is this a GitHub-specific issue? Will I have to deal with this in a provider-by-provider basis? Is there a protocol-level solution that miraculously makes the problem go away? Or is OAuth just not built with UX in mind?
FWIW I'm using iojs and passportjs, but I don't think that has anything to do with the question.
Turns out the issue was in my code, as it usually goes. I was explicitly setting a property (options.scope: [], for those using passport) on the authentication flow, and that resulted in a GitHub authorization URL that contained &scope=&, meaning I was explicitly asking for a downgrade.
Removing the option in case I have no explicit scope to ask for fixed the issue. Woo!
Related
For social authentication in node.js, I have seen a number of projects using the passport-facebook-token package instead of the default passport-facebook.
I am trying (and struggling) to understand the differences and benefits between these two packages - and how to choose one from the other. Any insights appreciated.
THE ANSWER
After a good bit of reading I believe I have understand (at least the basics), and am sharing here for the benefit of others:
passport-facebook uses an OAuth2 — Authorization Code Grant flow
passport-facebook-token uses an OAuth2 — Implicit Grant flow
See this great article on oauth flows for details of each of these. Some diagrams of the flows customized for these specific libraries can be found in this SO post.
GENERAL CONFUSION
Something that has become obvious in doing this research, is that there is a lot of confusion around authentication best practices. It is not clear to many (maybe most) exactly when each of the different PassportJS strategies (or flows) should be used.
SOME CONCLUSIONS:
Authorization Code Grant is more secure than Implicit Flow, as it does not share the third party access token directly with the user-agent (often a web-browser). Despite many articles to the contrary, this will work fine with SPAs as long as the SPA has "dedicated server-side component", such as a BFF-API (like the nestjs-bff I am trying to build... which is what started this whole line of investigation in the first place)
Implicit Grant represents an increased security vulnerabilities due to exposing the access token directly to the user-agent (often a web-browser). Use cases include SPA apps where there is no server-side component. Recently, industry best practices have been trending away from Implicit Grant and towards Authorization Code Grant, without the client secret, but with PCKE (Proof Key Code Exchange)... but that is typically recommended for native mobile apps, rather then SPAs.
MY NET TAKE-AWAY:
Use Authorization Code Grant (passport-facebook) over Implicit Grant (passport-facebook-token) if you have any dedicated server-side component to your client.
INVITATION TO CHIME IN!
I hope that helps others who found themselves with the same questions as I had. If anyone sees any errors, omissions, or incorrect assumptions about what I have written, please chime in.
I'm interested in creating a Linux Pluggable Authentication Module (PAM) that authenticates against Azure Active Directory. It appears that Oauth 2.0 is what Microsoft uses for this.
In reviewing the Authentication Scenarios it seems that the "Daemon or Server Application" probably makes the most sense, but I'm not positive. "Native Application to Web API" might also be a possibility, but all the app flows given show kicking off a pop-up browser instance to authenticate, which doesn't seem possible in PAM. As a result, unless I'm scrapping responses that flow doesn't appear to work, and scrapping responses seems like a bad idea.
My questions:
What is the best way to validate a user's credentials for this scenario? Is a Daemon or Native App?
What is the rough flow I would be looking at to do this? (e.g. If I'm using a Daemon, what calls do I make to validate the user creds?)
Any idea on what this looks like if 2FA is enabled for a user?
Thank-you for your help. I feel like none of the available options really fit here, and want to make sure I'm heading the right direction until I invest a bunch of time in here.
bureado's PAM you point to uses what's known as the OAuth "Resource Owner Password Credentials Grant". It basically takes the user's username & password and passes them to Azure AD for authentication. It has a bunch of limitations, several of which Vittorio describes here. A core problem you pointed out is that MFA does not work.
For scenarios like this Azure AD also supports the OAuth "Device Profile Flow". There's a code sample here that shows how to do it in .NET: https://github.com/Azure-Samples/active-directory-dotnet-deviceprofile. I'd recommend going that route.
Okay, I found the following module that appears to mostly do what I'm looking to do anyway:
https://github.com/bureado/aad-login
He chose to use "Native App". I'm still not positive if this is the "best option" and therefore I'm going to leave this open to other answers. I'd love it if someone could explain why this is the best option.
Meanwhile, I'm now trying to get AAD group memberships to be imported in like pam_ldap, or pam_kerberos, but I'm having a hard time figuring out how that's supposed to work, and have posted another question:
How to write a PAM module which changes group membership?
Should anyone come across this later and want to do the same thing, we're planning on open sourcing the final modified solution with this extended functionality. It doesn't do it yet, but the code is on GitHub here:
https://github.com/CyberNinjas/aad-login
I'm trying to secure my play application but I have no idea where to start. In play tutorial I have not found any chapter about that topic. As far as I see security topic is changing between play versions. So what are You guys using to secure Yours applications.
I'm new in Play so please forgive me if I'm asking obvious questions.
Edit:
Ok, maby question was't clear enough(I'm really sorry about that). When talking about security I mean that I need something to deal with users credentials and tool which allows me to restrict access to some pages and eventually to some rest actions in my application.
Edit2:
I'll try deadbolt2 now and we'll see how does it works. But I still encurage You guys to share Your knowledge about Play security with others:)
The documentation seems to still be a bit lacklustre on this topic, but essentially, authentication/authorisation functionality is usually performed using Action composition, which is the basis of reusable controller code in Play. There an example here (also linked from the docs that should help give you the general idea.)
Action composition in Play 2.2.x is done using ActionBuilders. These take a block which accepts a request and returns a Future[SimpleResult]. This allows the action builder to either execute the given block, or return a different Future[SimpleResult] (say, an Unauthorized in the case that a user's credentials did not check out.)
In our app we use the Play2-auth module for handling authentication with session cookies. This has (just) been updated to work with Play 2.2.x but uses a slightly different mechanism for action composition (stackable controllers.) You might be best off working out how the precise functionality you need can be accomplished just using the native framework tools before adding a dependency to it.
I agree with the other answers but just add that I use securesocial to integrate with other auth providers (google, FB, etc...), so I don't have to do auth myself. It's quite easy to get up and running.
https://github.com/jaliss/securesocial
Access control, security, etc. is a very wide topic, because it means very different things depending on context. This may be one of the reasons why Play has little documentation for it, which puzzled me at the beginning as well.
Play2 has some security helpers, namely it's the Authenticated method, for some insights on how to use it, check the comments in the source code. Its a simple method that you could implement yourself, and most do. It, essentially, just proposes a structure for where to place your methods that would check if request is authenticated and what to do if it's not.
Play2 also has some cryptography logic, which is used for signing cookies.
That's about it, you don't have any more pre-built security structures, but that's a good thing, because you don't want the framework making decisions like that for you, if it doesn't know in what context it will be used.
What is essential is to go and research how attacks relevant to your application are carried out, best practices and so on. I recommend going to OWASP, particularly the OWASP Cheat Sheets. If the list of Cheat Sheets seems intimidating start with the OWASP Top Ten Cheat Sheet. Don't mind the large volume of information, it's very useful knowledge.
I have been building quite a few MVC based websites locally and am finally ready to deploy the first, but, I am getting rather nervous.
During testing, I noticed several things that worried me - I am using the default forms authentication with a few tweaks (although nothing to the underlining security).
I noticed that if I created a user in one application and logged in, then launched another application... it would keep me logged in* as the user from the previous application. The user doesn't even exist in the new application!
* - I used [Authorize] on controllers, and was surprised I could just get straight in without any sort of authentication
I assume it is because the cookie is being set for localhost instead of the application/port (although, not too much I can do about this in development).
Based on this, how secure is the default authentication?
1. Is there anyway to check from the code that the user doesn't have a "faked" cookie? / Check the user has logged in from my application?
2. I was just wondering if there are any sort of check lists or anything I can go through before deploying?
Sort of - 3.As of writing this, For question 1. I am guessing I could add a column with a random number that is saved to the cookie, and then that number is checked every time any authentication is done... however, I did not want to start mucking around with the membership provider... but I think this could work. Is this a good idea?
Try using IIS on your machine instead of VS Dev Server. Solves your problem 1.
Other than that I don't think you will need any extra effort to make default membership mechanisms of asp.net to make more secure if of course you don't need a real custom things to do in your projects. These things are around for a while now and I think they have been well tested in terms of security.
You just need to remember to put [Authorize] attribute to right places. If not on your controllers put them to right methods.
Basic Web Authentication shouldn't be trusted for applications which contain truly sensitive information. That being said it's sufficient for most applications. Be sure to check your application as often as possible before and after release for XSS vulnerabilities.
Here is Microsoft's recommended "Secure yourself" list. http://msdn.microsoft.com/en-us/library/ff649310.aspx
No matter how strong your authentication is, one small XSS mistake and a malicious user can do as they wish to your site, and your users data!
I recently read a good book: Worx Professional ASP.NET, it talks about these steps in more detail on securing yourself as well as exposing examples of problems. After reading this I was able to "deface and steal" my own sites information with relative ease, was a good eye opener on the importance of securing for XSS.
I'm working on a web site and I plan to use strictly OAuth in for user authentication. I've never implemented session management/user authentication before; and so - naturally - I'm reading up on a lot of how tos to get this done.
The problem I'm running into is that a lot of examples out there for doing things like setting up your realm, authenticator, etc etc seem to rely on the user/password paradigm for authentication. The whole point of going for OAuth is to avoid this in the first place!
That being said; I'm actually not looking for examples of full OAuth implementations right now. I understand that I need to understand that for myself. BUT with a future OAuth implementation in mind; how should I structure my user authentication/session management FOR THE TIME BEING in a way that will allow me to move forward on developing the functionality on my site that I really care about? I suppose I could throw some stuff together for that; but I'm just afraid that down the road I will be shoe horning an OAuth implementation as opposed to do something now which allows me to lay down the basic framework for it and then move on to other things.
So; does anyone know of a good example of laying the groundwork for OAuth on Tomcat 7? For example, which authentication mechanism (Basic, digest, etc) I should use or how I should represent user credentials in my database?
I know that this is kind of a vague question; so I'm not expecting someone to come out and tell me all of the answers I need to know. I'm just looking to get pointed in the right direction here.
Perhaps Spring Security would be useful? Your webapp could leverage Spring Security and use whatever login mechanism you need (i.e., you could do the default form-based authentication or Basic Auth for now, and replace the login/auth piece with an OAuth implementation when you're ready), but still have Spring Security manage authorization to particular resources in your webapp.
Someone has also built OAuth for Spring Security, so it may be a useful addition to your web app all around.