
Show HN: A microservice that makes adding authentication to your app easy - hypebeast
https://github.com/hypebeast/micro-auth
======
arekkas
Never, ever use access tokens as proof of identity the way you are doing it.
It makes you vulnerable to token substitution attacks. OAuth2 is not an
authentication protocol.

[https://oauth.net/articles/authentication/](https://oauth.net/articles/authentication/)

DO NOT USE THIS in its current state. Stop upvoting this.

~~~
rblatz
So how would this apply to using a JWT as a bearer token?

~~~
snuxoll
JWT is designed for authentication, it's what OpenID connect is based on (in
conjunction with OAuth 2.0).

~~~
arekkas
No. A JSON Web Token defines a compact and self-contained way for securely
transmitting information between parties as a JSON object

------
JoshMandel
I applaud the goal of simplifying authentication by wrapping with an easy-to-
use service. But it's important to keep in mind that authentication is a
subtle process, and a critical security component of many applications!

It's essential to follow best practices, and for developers to understand
enough of the interaction to be confident in an implementation.

A few points to look out for after scanning the source for the project:

* if your goal is authentication (helping a user sign in to an app using an external identity) you should be sure to use an OpenID Connect flow (requesting a scope like "openid"), and be sure to convey the id_token back to the app so its signature can be verified.

* you should be sure to create a non-guessable "state" parameter when generating an OAuth authorization request, and to verify this parameter upon completion of the OAuth core flow.

* your design needs to prevent a session fixation attack where a malicious user injects her own token into the callback url (tricking a user into signing into an app using the attacker's account, and potentially submitting data that the attacker can then access the)

* it's best to avoid inserting an access token into a url (where it becomes part of a user's history, gets cached by proxies, etc) -- the OAuth code flow you're using avoids this, but then you turn around and inject the token into your own redirect

------
ziikutv
"It's build with Nginx/OpenResty, Lapis and Docker. This enables the service
to be very performant and requires only minimal system resources."

So does this mean I need to have Docker and all of the other things mentioned
to use this?

Suggestion: Don't couple your product with dev-ops stuff. Try to keep things
separate :)

~~~
derefr
Re: all the other things mentioned — I presume the point of Docker in that
list is that the system-software packages mentioned are _inside_ the shipped
Docker image. It's an "appliance."

"Ships as a Docker image" might, for a lot of projects, just be a roundabout
version of "it's a .zip file; unpack it into /opt"—but I think it's justified
if your project is essentially a bunch of distro packages with a layer of
policy-glue making them interoperate in a special way. Like OpenStack
DevStack, or a NAS server appliance, or an "all-in-one" [L]AMP stack.

~~~
ziikutv
Fair enough. However, my opinion of this matter still stands. I think
something like a library or even an executable/process should try to decouple
itself from deployment process; and should be designed as such. Its very
opinionated - I must admit - but it tends to take away a lot of friction from
adopting. Also, usually, when we add things like Docker to the mix, it is
quiet unclear if the said microservice can function without Docker (perhaps
it's using something X specific and cannot work without it); if it can, lets
mention it otherwise even if it is something I want, I won't spend the time to
test it myself (yeah I am very a very picky lad I know but I bet this is
something a lot of people do)

~~~
computerex
What are you talking about. Docker is a tool that _positively_ contributes to
the deployment experience and _reduces_ friction in adoption. It is one of the
tools that directly contributed to the adoption of microservices because it
makes dealing with a large number of services (500+) sane and possible.

You should learn more about docker and dev-ops, because with microservices the
focus is increasingly towards having developers support their services end-to-
end, which means the devs are responsible for deploying/supporting the
services they wrote in production.

~~~
collyw
>Docker is a tool that positively contributes to the deployment experience and
reduces friction in adoption.

Well its one more things to install for starters. Do I need a specific version
of docker to run with this? To me it's just an extra layer of complexity.

------
bungle
Nicely done! If you don't mind, I added it to my awesome-resty list
([https://github.com/bungle/awesome-resty](https://github.com/bungle/awesome-
resty)).

~~~
smt88
Please see the comment about how insecure this is[1] and do NOT add it to your
list.

1\.
[https://news.ycombinator.com/item?id=13682682](https://news.ycombinator.com/item?id=13682682)

~~~
bungle
I added a remark there. Thank you.

------
abraae
See also oauth2_proxy from bitly:
[https://github.com/bitly/oauth2_proxy](https://github.com/bitly/oauth2_proxy)

------
LeonidBugaev
Well, personally I prefer using something like
[https://github.com/TykTechnologies/tyk](https://github.com/TykTechnologies/tyk)
which basically API Gateway, and in addition to auth (not only oAuth), also
adds stuff like policies across multiple API's and rate-limiting and quotas.

------
failrate
OpenID Connect is already almost trivially easy to implement with broad
library support.

------
duncan-donuts
Check out [https://github.com/portier](https://github.com/portier)

