Is ORY/Hydra pretty much the same thing as Okta and Auth0 expect that Hydra is open-source and has limited support compared to the later ones?
Related
I want to create custom made algorithm for web access token vs using JWT.
My algorithm will use XOR with secret key in order to encrypt.
so for example : for {username : user, timestamp : 1212121, md5 of the above} I will xor it with secret key and send it to the user.
The benefit for me is that attackers will have hard time to guess how I built the encryption vs well known JWT. So trying to send me a cookie with admin/another user will be harder for him.
My main question is why to use JWT and not creating your own algorithm which will be harder for attacker to reverse engineer ?
Tnx
It's because no algorithm is fully sound; people make mistakes, a lot, in ways that you probably wouldn't have predicted. Then there is the maintainability aspect that even if you're an A grade expert on these kinds of things, you have to maintain that algorithm. And is that really something you want to be doing over providing business value?
Also, the advantage of using well known standards for authorization, encryption, etc. is that they have proven (as far as possible) that they are secure 'enough' for at least the near future and extensively tested as they are used by billions of sites/apps on a daily basis.
So summarizing: it's just not worth the effort, and the probabilty and cost of a mistake is too high..
Using xor with a secret key means that you will not be able to use asymmetric keys, so any client which needs to decrypt the token will have to know the secret, and thus will be able to encrypt tokens as well.
If your client does not need to decrypt tokens, then you can just use opaque tokens, you don't need JWTs. (Or use the Phantom Token Pattern if your APIs do need JWTs but clients don't).
If your client does encrypt the token, then any attacker can easily read your solution and it's no longer that secure. Also choosing your own solution because it will be harder for anyone to guess it is security by obscurity and does not add real value (e.g. a hacker could do a research about you and your code and maybe will find this post on SO, which will give her valuable information about your solution).
When you choose standards for security solutions at least you know what are the potential issues, and how to properly address them so your project remains secure. If you choose a proprietary solution, then you will not know the security issues that you have.
What technical detail should programmers consider while developing their own oAuth service?
Have been trying to find out guidelines, but found most of the oAuth related articles discuss as a consumer point of view (i.e. how to consume others service). I want to design my own oAuth system with my authorization service and resource service. What technical detail should I follow?
You probably have read the RFCs but just in case you haven't, they're the place you want to start:
oAuth 2.0 "core" (RFCs 6749 and 6750)
Proof Key for Code Exchange (PKCE) (RFC 7636)
The best 'packaged' guidance for oAuth implementers (client or otherwise) is available via IETF Best Current Practices (BCPs). Most people know about IETF RFCs and (confusingly) BCPs are published as RFCs with a RFC number. Despite that, they're best practices and not formal specifications:
The BCP process is similar to that for proposed standards. The BCP is
submitted to the IESG for review, and the existing review process
applies, including a "last call" on the IETF announcement mailing
list. However, once the IESG has approved the document, the process
ends and the document is published. The resulting document is viewed as having the
technical approval of the IETF, but it is not, and cannot become an official Internet Standard.
BCPs you want to review:
oAuth security (up to date as of this writing)
oAuth for browser-based apps (up to date as of this writing).
oAuth for native apps (published in 2017 as an update to "core" oAuth 2.0 RFC, still a good read)
JSON Web Tokens for oAuth (up to date)
These documents are framed in threat model terms - they cover attacks (or "security considerations" as a diluted format) and countermeasures. You might be looking for a more straightforward building blocks type of a roadmap and perhaps there should be one as an educational tool. Real-world oAuth implementations must be developed with a prima facie evidence of a threat model.
As one samurai said: ...swordsmanship untested in battle is like the art of swimming mastered on land.
I would also be interested to hear why you want to develop your own auth solution.
But putting that aside, there is an open source project that does exactly what you ask - Identity Server. You can check out their source code or fork it and build something on top of it.
Also, please check "identigral" answer on various docs.
I work for a company which prohibits the use of open source and, for some reasons, I wouldn't be able to buy a single sign on solution from the market. Is there some tutorial which could explain what is envolving in developing a single sign on solution? This can be done in Java or Dot Net as long it is able to communicate with LDAP. Any idea will be appreciated.
On the wikipedia page List of single sign-on implementations you can find a list of SSO implementations, there is a column indicating the licence. Some of them are open-source, you should start a comparison of them to find which best suits your buisness requirements.
I can't recommand you to rewrite a SSO from scratch, it will cost you more time than choosing an existing free and open-source implementation, and your home-made implementation is subject to security issues if you don't have the right expert guy working on it.
I'd go with SAML.
It's an open standard used for sso solutions. In fact, i worked at a company where we built our own SSO around this.
And for LDAP integration, you can build something by yourself, or check Microsoft's Active Directory Federation Server, which I think is SAML-compatible
What makes most sense for large enterprise applications involving several jsps and many transactions (like a commercial banking application or a healthcare application with huge amounts of data) w.r.t templating? Is it just a matter of personal choice or is there a strong reason to lean towards server-side templating?
Client-side templating is more matter of UI and should not be confused with backend transactions in any way. When your site does something it is still doing HTTP POST which is processed by the server logic. I saw the development more like a natural continuum to build easier to use web enabled by the modern browsers and Javascript engines.
You might find some more info here:
https://github.com/leonidas/transparency/wiki/Frequently-Asked-Questions
I am really curious to know how Google Buzz and Facebook implement their comment feature which is being updated instantly. is it similar to Google wave technology? are there any resources to learn that technology and implement it to our website?
Thanks !!
I work on the Google Buzz team, so hopefully I can give you a good answer for our side of the equation. I obviously won't go into any of the confidential backend stuff, but I'm happy to address the open standards we use and the open source projects involved.
Starting in the UI space, we use technologies like Closure and GWT to build rich, responsive user interfaces. We use a technology vaguely similar to what you see in the Google App Engine Channel API to push real-time updates to the users. GAE is a really good choice for real-time web applications right now.
On the API side of things, we try to use open standards wherever possible. We use the Atom syndication format to enable feed readers to consume Buzz content, and Pubsubhubbub to enable real-time pushes of the content. In fact, we use Pubsubhubbub for our activity firehose — it's possible to subscribe to the entire real-time stream of all updates that happen in Buzz. Needless to say, this sends a massive amount of traffic to your application. On the JSON side of the equation, we use Activity Streams, and we're actively working with the community to refine and improve that specification. Our Atom feeds include Activity Streams as well, but the focus there is on syndication. All our secured API endpoints for Buzz use the OAuth standard for authorization.
On the backend, I think the only thing we're willing to say publicly is that Protocol Buffers are pretty awesome.
The technology is called Real-time web (http://en.wikipedia.org/wiki/Real-time_web). You have many application models to achieve real-time and one of them is Comet (http://en.wikipedia.org/wiki/Comet_%28programming%29). Good server to use it in your implementation is APE (http://www.ape-project.org/). It supports many common javascript frameworks. More you can check in provided links.