<p>I love the Auth* space. It has so many different problems, so many scopes and so many use cases to tackle. I've been working with our european <a href="https://www.lrz.de/services/compute/grid_en/">Grid</a> in the last year and written or contributed to various auth libraries like <a href="https://github.com/ZF-Commons/zfc-rbac">zfc-rbac</a> or <a href="https://github.com/ory-am/hydra">Hydra</a> in the past. I never thought that the day would come, where I find certificates attractive. ;)</p>
<p>Before we go ahead, here is the <strong><a href="https://github.com/ory-am/fosite">Fosite project on GitHub</a></strong> and I've already done a lot of stuff. Continue reading to understand what Fosite solves and why.</p>
<p>I believe that OAuth2 and OpenID Connect are well defined specs and that there are most definitely good OAuth2 libraries out there. But in the Go eco-stytem, the most common one, <a href="https://github.com/RangelReale/osin">Osin</a>, has shown various weaknesses (<a href="https://github.com/RangelReale/osin/pull/103">a</a>, <a href="https://github.com/RangelReale/osin/issues/107">b</a>) and is difficult to extend. Osin is <a href="https://github.com/RangelReale/osin/issues/107#issuecomment-169663878">not going to progress on security</a> as pointed out by the author and I agree on that decision.</p>
<p>OAuth2 does not only come with the ominous <a href="http://tools.ietf.org/html/rfc6749">rfc6749 spec</a>, there is also another less known but as important RFC called <a href="https://tools.ietf.org/html/rfc6819">RFC6819 "OAuth 2.0 Threat Model and Security Considerations"</a>. I am writing a library that is secure, fast, extensible, implements the original OAuth2 spec and counterfeits attack scenarios described in rfc6819. All of these things <strong>do</strong> matter if you are using OAuth2, be it due to opening up your api to the unknown internet, increasing network traffic with token lookups, or adding new specs like OpenID Connect on top of OAuth2. Nobody wants to be responsible for leaving the security gate wide-open.</p>
<p>The OAuth2 framework I am working on is called <a href="https://github.com/ory-am/fosite">Fosite</a> and there is already a lot of stuff being done. Help me build the <strong>most badass OAuth2 library in existence</strong> and put <strong>Go on top of the auth micro-service food chain</strong> - and claim your spot in the <a href="https://github.com/ory-am/fosite#hall-of-fame">Hall of Fame</a>. ;)</p>
<p>I appreciate any help, feedback or suggestions . I am not writing this library for personal gain but for the devs that want to build secure applications, because I had to solve these problems many times, made many mistakes and am finally confident that I can get this right, if you help me.</p>
<p>See you on the other side.</p>
<hr/>**评论：**<br/><br/>tty5: <pre><p>Main author of OAuth2 spec believes it's so bad he wants nothing to do with it:</p>
<p><a href="http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/">http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/</a></p></pre>machete143: <pre><p>The issues pointed out there are exactly why fosite counterfeits threats defined in <a href="https://tools.ietf.org/html/rfc6819">rfc6819</a>.</p>
<blockquote>
<p>I think the OAuth brand is in decline. This framework will live for a while, and given the lack of alternatives, it will gain widespread adoption. But we are also likely to see major security failures in the next couple of years and the slow but steady devaluation of the brand. It will be another hated protocol you are stuck with.</p>
</blockquote>
<p>This post was in 2012 and almost 4 years later his vision has not become a reality. Actually, with the rise of OpenID Connect I in fact believe that he is wrong and a generic but extensible "security framework" (his words) is actually exactly, what the world needed.</p>
<p>To conclude, making OAuth2 secure is <strong>no joke</strong> which is <strong>exactly why I'm writing fosite</strong>. Because the implementations I saw where in fact <strong>not secure</strong>.</p></pre>dasacc22: <pre><p>I have a package (not public) I developed to provide a strict subset of bearer token authorization. I mention this to share my thoughts that so many do-everything libraries out there have so many vectors for errors that it makes me uncomfortable. When I only need a specific path through those features but functionality unrelated to my needs are apt for abuse and thus my app can be abused, I'm troubled further.</p>
<p>With that said, an oauth package with parts I could compose simply to provide only needed functionality might entice me to at least consider it.</p></pre>machete143: <pre><p>Thank you for your thoughts. I am working hard to make this framework as flexible as possible. Right now I plan to make it possible to completely remove the inner parts and replace them with your solution for handling an authorize_code or similar. Of course the library is going to do most of the grunt-work in checking wether or not the request is valid. I am trying to make this part as transparent as possible by writing a ton of tests and carefully documenting which part of the RFC this test covers.</p>
<p>Feel free to check out the current handler facing-api:</p>
<ul>
<li><a href="https://github.com/ory-am/fosite#authorize-endpoint" rel="nofollow">https://github.com/ory-am/fosite#authorize-endpoint</a></li>
<li><a href="https://github.com/ory-am/fosite#token-endpoint" rel="nofollow">https://github.com/ory-am/fosite#token-endpoint</a></li>
</ul>
<p>This looks easy, but by replacing e.g. the ResponseTypeHandlers with:</p>
<p>oauth2.ResponseTypeHandlers = []fosite.ResponseTypeHandler{MyCustomHandler{}}</p>
<p>you can do crazy stuff.</p>
<p>Hope this could raise your interest. :)</p></pre>machete143: <pre><p>One more thing, the framework is designed to be replaceable, so if you don't like my implementation you can switch it out for yours.</p></pre>daniel_chatfield: <pre><p>This is looking really good, you might want to share on <a href="/r/security" rel="nofollow">/r/security</a> as well.</p>
<p>As far as I can see with this implementation the OAuth token is still a golden ticket, if an attacker can get at it in the network stream they can do whatever they like. </p></pre>machete143: <pre><p>Yes, this is unfortunately the weakness of OAuth2. The token is comparable with 5 bucks. You can pay with it but nobody really cares where it comes from.</p></pre>machete143: <pre><p><a href="https://www.reddit.com/r/security/comments/3zy5zj/im_building_the_most_badass_securityfirst_oauth2/" rel="nofollow">https://www.reddit.com/r/security/comments/3zy5zj/im_building_the_most_badass_securityfirst_oauth2/</a> :)</p></pre>petulant_snowflake: <pre><p>You seem to be only committing on the 'unstaged' branch -- this makes use with 'go get' out of the box non intuitive.</p></pre>machete143: <pre><p>This is intentional because the API is not finalized yet and I want people not be hit by BC breaks every day :)</p></pre>SulfurousAsh: <pre><p>Good luck! Btw.. your tagline on Github should be <code>era</code> and not <code>aera</code>.</p></pre>machete143: <pre><p>thanks, corrected :)</p></pre>ifuporg: <pre><p>Take a look at <a href="https://github.com/CoreOS/dex" rel="nofollow">https://github.com/CoreOS/dex</a> too</p></pre>machete143: <pre><p>yup, I looked at their workflow :) </p></pre>nohoudini: <pre><p>Will it get a bad ass documentation as well? =)
EDIT: I mean so I can learn how to implement it secure & correct.</p></pre>machete143: <pre><p>i will do my best!</p></pre>machete143: <pre><p>Hey, thanks for the massive feedback and interest in the project :) Do you know any good channels where I could promote this library so it gets reviewed by as many people as possible?</p></pre>
