I just want to know brief explanation of OIDC standards that all the applications must follow. I have found a book https://openid.net/specs/openid-connect-core-1_0.html#RFC2119 about OIDC standards but I just want a brief explanation if anybody can provide
Thanks
Unfortunately the answer is "it depends". It depends on what you are protecting, how you decide to implement this protection, and if you choose to use the OIDC compliant aspects or not.
A good entry point into this discussion in regards to Auth0 is with their OIDC Adoption Guide. That will link you to many other resources based on what you're looking for.
Related
I have spent the past three days researching OAuth 2.0 and I understood how OAuth can be used to interact with a service provided by a heavy weight such as Google or Facebook. However, I'm struggling to see how someone without a team of tech wizards (aka Me) goes about protecting their API with the protocol.
I have a number of questions and was wondering if someone with some experience can help me.
Here goes nothing...
Is there a clear cut leader in terms of an OAuth Authorization Server implementation (Java)? If yes, is there any good resource out there to teach me how to use it?
Its my understanding that I would need to either build an authorization server or leverage a library to dish out client secrets/tokens.
Should I even be thinking about a library or should I be building my own implementation?
Is OAuth still relevant? From what I can see, it seems like the hype around the technology has leveled off or diminished since 2010. I also saw an article where the spec lead disassociated himself from the protocol.
I appreciate any advice or help, I can't find many resources on this topic that address it clearly (tons of Powerpoints, no code). There seems to be a bunch of talk about how it works, yet no book or article can give a solid tutorial. The documentation for the providers I have found is also very spotty at best. I'm just really starting to question whether this is a legitimate undertaking for someone looking to protect their own simple API. Thanks ahead of time.
Take a look at the Libraries on the OpenID Connect developer pages here: http://openid.net/developers/libraries/
I don't think there's a clear cut leading Java implementation yet
I would not recommend implementing the Authorization Server part on your own, that is the complex part and details matter because this is about security; the client part is easier and should be possible to build even without a library
OAuth is very relevant as it is the only standard out there for securing REST APIs; the hype is over, and now it is common technology; just take a look at all big vendors/SaaS out there, they all use it (starting with Google, Microsoft, Facebook, Twitter etc.)
I feel a bit overwhelmed right now with how to approach building an SSO solution for a project I'm taking on. I understand that I need a centralized login site, but, I'd like input on what framework I should be using to achieve this. I've been reading a bit about Windows Identity Foundation (WIF), but, the lack of documentation and code samples is quite disappointing. DotNotOpenAuth sounds like it has much more usage by the community than WIF, but, I'm not sure if that's the right framework for me to use given that I am not going to be letting third-party accounts be used for logging in.
There are multiple user data stores to take into account as well; active directory and a SQL Server database.
I really don't care what framework I use so long as it's simple and intuitive; I don't want an overly complex solution. Documentation and samples are also a plus! I already have experience with creating custom role providers and membership providers; those were a breeze and easy to do.
Here is a very quick visual of the structure I'm dealing with:
Refer: Claims Based Identity & Access Control Guide and Identity Developer Training Kit. There's WIF samples there.
In terms of what you want to achieve, ADFS v2.0 will get you most of the way but it can only authenticate against AD. For SQL server, use IdentityServer and then federate ADFS and IdentityServer.
Have a look at SAML. It is designed to address SSO. You may also want to look into OpenID.
There are enterprise products out there, such as CA Site Minder or IBM Tivoli for this kind if thing. They are not cheap because building a custom solution for this will be quite a feat.
If you are .NET based - then .NET 4.5 (which includes WIF) is the way to go.
But the framework will be you simplest problem. Building that kind of security infrastructure is hard. Have a look at both the book and idenitity server from nzpcmad's answer as a starting point.
As far as cross-platform goes, SAML tends to lead the pack. There are many implementations (java, php, perl). As Dominick (#leastprivilege) mentioned, if every application is .Net based, WS-Fed via WIF is the way to go. (btw, Dominick is the man when it comes to WIF - definitely hit his blog and forums up if you plan on exploring that route)
OpenId and OAuth are alternatives that you will hear about. They are somewhat less secure (the trust is in the user, rather than the infrastructure) and you will find that you will have to build a provider in order to support sign-in using your own user store.
Regardless of the route you choose, be prepared to do a lot of reading and learning. Check out the wikipedia articles above for a nice overview of how these technologies work, and don't be afraid to ask questions..
I am going to start writing an API for my open source project.
Should I go with OAuth 2 for authentication or OAuth 1?
My main concern with OAuth 1 is than I don't want to invest time in writing API based on it if OAuth 1 going to be outdated soon.
My question is - will OAuth 1 become outdated soon? Also, I think from the point of end-user of the API, OAuth 2 seems to be easier to implement.
Should I just write OAuth2 API and forget about OAuth 1 or are there good reasons to use OAuth 1 for now?
Use OAuth 2.0. It is stable and ready for implementation. There is no reason anyone should be deploying OAuth 1.0 at this point. 2.0 is simpler, more secure, and more robust.
As for 1.0, the protocol is published and anyone can use it as long as they want. It is an information RFC and will remain that way. However, once 2.0 is published, 1.0 will be marked as obsolete. None of this IETF bureaucracy should make any difference to you.
OAuth 2 is in draft stage (current writing, draft 16), but OAuth 1 has already is already in RFC (RFC 5849).
OAuth 2 authorization flow is easier than OAuth 1 but what you might encounter is that you have to choose a draft you want to implement and stick with it. When an RFC for OAuth 2 will be released, you will have to conform to it.
Addon: If OAuth 1 will be obsolete, the RFC will be obsoleted. The IETF will put the RFC into Status "historic". Chances are, they might make OAuth 2 an RFC and historicalize OAuth 1 RFC. Until that happens, OAuth 1 is valid to this day.
I hope this little info can help you.
You should think about your users (developers) and choose an appropriate API based on that. Are they likely to have experience or a preference? If not I'd tend to go for OAuth2. You might also want to make the decision based on the type of organization you are dealing with. I've dealt with people who have a preference for older protocols because they feel they are more mature and secure. This is not always rational but sometimes it is worth considering.
There is some information on design decisions (why a new version?) driving Oauth2 available.
I am worried about the future of OAuth, seriously. Since Eran Hammer, one of the founder of the OAuth left the group and later David Recordon followed him.
They are concerned about the security and vulnerability of OAuth 2.0. This is how Hammer described OAuth2.0
more complex, less interoperable, less useful, more incomplete, and
most importantly, less secure.
May be its time to look at SAML for the OAuth users.
Where can I find useful documentation about using Shibboleth and SAML for SSO besides the Shibboleth Wiki pages, preferably for Ruby applications? Ruby-specific documentation for Shibboleth seems to be very sparse. Does anyone know good resources, tutorials or HowTos?
Unfortunately, the only useful documentation I found is the official documentation from the creators of Shibboleth and SAML themselves. This seems to be a good technical overview about SAML 2 in general from the standards organization OASIS: Security Assertion Markup Language (SAML) V2.0 Technical Overview. One can also read the complete SAML specifications, but I doubt this will be a good start. The only authorative source for Shibboleth seems to be the Shibboleth Wiki itself.
These links will help you.
http://www.imrantariq.com/blog/?s=saml
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUsrManJavaInstall
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,