tangui
I’m glad to release the first version of Plugoid, an OpenID Connect library for Phoenix.
This library can be useful if you delegate authentication completely to an OpenID Connect Provider.
Example configuration:
defmodule MyApp.Router do
use MyApp, :router
use Plugoid.RedirectURI
pipeline :oidc_auth do
plug Plugoid,
issuer: "https://repentant-brief-fishingcat.gigalixirapp.com",
client_id: "client1",
client_config: MyApp.OpenIDConnect.Client
end
scope "/private", MyApp do
pipe_through :browser
pipe_through :oidc_auth
get "/", PageController, :index
post "/", PageController, :index
end
end
More information here:
Although it’s version 0.1.0, it has a quite comprehensive support of the standard (see the README for more information). Any feedback is welcome on the issue tracker!
You can try it out with the https://github.com/tanguilp/plugoid_demo application.

For those working with OAuth2 or OpenID Connect, a few additional libraries that were needed to build Plugoid could prove useful:
Oauth2MetadataUpdater: retrieves OAuth2 and OpenID Connect metadataJWKSURIUpdater: JWKS key downloaderOAuth2TokenManager: manages OAuth2 tokens and OpenID Connect claims and ID tokensJOSEUtils: Convenience functions to work with JOSE (JSON Object Signing and Encryption) on top of theJOSElibraryTeslaOAuth2ClientAuth: Tesla middlewares for OAuth2 and OpenID Connect client authentication
Also I’ve seen that some people were looking for some project to contribute too - for those, feel free to look at the issue trackers of these libraries and contact me if you’re interested on working on an issue.
Have a good evening!
Trending in Announcing
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex










Showing Posts 1 to 9- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Exadra37
Congrats for your release
Some questions
Do you enforce the use of
stateandnoncewhen getting the OpenID Connect Token?Do you verify the
stateparam in the provider callback?Do you verify the
nonceand theat_hashin the OpenID Connect token claims?tangui
Thanks!
State is always used, this is how we found the challenge when redirected back from the OP. Nonce is used when mandatory (implicit and hybrid flows), but can be forced with the
:use_nonceoption.Depends what you mean by verify, but the state is used to match the correct OIDC challenge generated before redirecting to the OP. State is a secure random string (and not a encrypted token).
Yes, and also
"c_hash". Nonce can also be checked against replay (see the:jti_registeroption inPlugoid.RedirectURI, the demo app uses it).Exadra37
So this means that by default you are open to replay attacks. I enforce the use of a nonce as an encrypted token in my implementation.
In my opinion security should be opt-out not opt-in, therefore I would prefer to this parameter be used by default, and if people really want to disable it then you gaive them that option with
:disable_nonce.By verify I mean to check that was the one you sent, but it seems that you do it, once you use to match the correct OIDC, but I have not looked into your code.
I prefer encrypted tokens, because then I can check the signature and the expire time. Call me paranoid, but with hackers security is never enough.
Thats awesome
Awesome that you detect replay attacks :), but its a pity that is not enforced by default as I mention above.
tangui
Thanks for your feedback!
Not in the authorization code flow, because the authorization code can be used only once. And nonce is used in the other flows. Also, PKCE is used by default (if supported by the server) which adds another layer of defense.
Good point, I think I should add a maximum timeout for challenges.
It would be useless in the authorization code flow, and also it’s hard to setup a distributed token ID register from a library but I plan to work on this point. That said, the library defaults to the implicit flow with
"form_post"response type if available at the OP (and authorization code flow otherwise). I don’t see a scenario where an attacker could access POST data without having access to browser cookies (in which case protecting against replay is meaningless) but I’ll review this choice further.Exadra37
I forgot to elaborate in the expire time, but that is for what I use it, aka to not allow a challenge to succeed after x seconds have passed.
In my lib implementation I don’t give feedback about the reason it fails, I just ask the user to retry.
Can you elaborate why you think it’s useless?
That’s what
:etsand/or:mnesiaare good for, and I plan to use them in my lib. Take a sneak peak to Pow to how it is done there in a distributed way.A Man in the Middle attack is one scenario, leaked cookies to the server logs another. Anyway this cookies should have the
secureandhttponlyflag to prevent being stolen by javascript on the page.I work in the security space and another attack vector that is common for us to observe in the wild is that the user of your application gives away his authorization token to a third party service that will help him to take advantage of stuff is not allowed to, like earning more reward points.
EDIT:
Another attack vector are browser extensions, they have away too much power you cannot control, and the browsers extensions store are full of malicious browser extensions, and others are just tracking you and they can grab all sorts of data that you may not expect or want them to send to their tracking systems.
If you read this article from the security researcher Troy Hunt you see this:
So go ahead and also read the article he mentions in the quote: Malicious Chrome extensions infect 100,000-plus users, again:
Or see this Tweet https://twitter.com/nikolaihampton/status/1037449795604905985:
Or this one Hackers Extracted and Published Facebook Private Messages Grabbed Through Bad Browser Plug-Ins:
tangui
Actually, why do we need it? First thing to come to mind is bruteforce attack on the state parameter but what for…
Because when redirected back from the OP the RP receives an authorization code that can be used only once on the OP in exchange for the ID token (and optionally access token and refresh token). Once it is used on the OP, the OP deletes it and therefore it cannot be replayed. It could be intercepted in the browser URL (say, through a malicious script) but PKCE deals with that threat. So I see no replay attack scenario possible in this authorization flow.
JTIRegister library comes with an ETS implementation. As for Mnesia, it is still hard to have it working:
I’d like to write such a library that would make using Mnesia as easy as ETS, but I lack time
It’s the default setting for
Plugoid, plusSameSite=laxfor the authentication cookie (as described in the Cookie configuration section).That’s actually the question behind the default flow used by Plugoid (implicit with response type
"id_token"and response mode"form_post"). Is there a scenario where a malicious extension could access the body of an incoming POST request, but not cookies? Because OpenID Connect is all about opening an authentication session, and an attacker wouldn’t need to steal an ID token if it could simply steal the authentication cookie.Exadra37
I still have a lot to learn about OpenID Connect and all the attack vectors it may be possible, but at a first glance it looks like the mix up attack and other attacks described in this article can be of harm?
Anyway my lack of a more deep knowledge on OAuth flows doesn’t allow me to be more assertive, only cautious
Nice to know about this one
For the nonce I just need to keep them around for the x amount of time I decided that the encrypted token for the nonce should be valid for, thus issues with netsplits should not a huge issue in the event of one happening. Yes it could cause some disruption, but would be in a very small window. To manage netsplits you can use unsplit or reunion that is a rewrite of unsplit.
I am using Memento, but you also have ecto3_mensia in active development.
I am not a pent tester, neither have played with browser extensions, but it looks they are given a lot of permissions by the browser to manipulate what happens in your page, thus I believe they can extract anything they want from your request(maybe except cookies), but I may be wrong. Maybe @voltone can be of help here?
tangui
Thanks again for the feedback!
I think not, as Plugoid uses automatic configuration by default. Also, the OP is hardcoded (
"issuer") in the router’s pipeline configuration.Ha, didn;t know reunion, looks interesting!
After a quick search it seems an extension can indeed read cookies on Chrome and Firefox (with some restrictions on Firefox).
tangui
Following @Exadra37’s feedback, I’ve added protection against mix-up attacks in version 0.4.0.
It seems that a few people are using it judging by the downloads, so please feel free to share feedback about this library here, on Github, or any other place.
Have a great day!