Asteroid - an OAuth2 server

This is really awesome! Had this been here before we might have gone this path instead of Keycloak.

Great work! I have some questions if you don’t mind:

• Why isn’t the docs hosted on hexdocs?
• You mention here that hex does not guarantee the integrity of packages but it is my understanding that it does. Here is the specification about it. Could you explain this part better?

One thing that might help you with such a big project is to create an organization on GHub and put your projects there. This might entice more people to contribute.

Thanks for your awesome work!

Thanks, means a lot!

So I checked something like 1.5 year ago and at that time my understanding was that you couldn’t be sure that the code you receive was the code that was sent by the updater. I’ve checked again quickly (thanks for the link):

• Still not sure how it’s possible to make sure the received package is the one sent by the maintainer. After sending it to hex.pm, is it possible to substitute it with another one (with a valid checksum)? I can see checksums here: https://hexpm.docs.apiary.io so how can the hex client check it receives the correct checksum for a package?
• I don’t understand neither when packages are signed: directly after uploading? Or when served?

Don’t get me wrong, hex.pm is a great package manager and I love using it. On the contrary, referencing git reps in mix.exs is a pain as soon as you have different versions for the same lib. But I’d like to understand the sec tradeoffs of using hex.pm first, especially for sensitive security-releated libs.

Didn’t think of it, that’s a good idea!

Which makes me think I forgot to thank the community that has been super helpful and open on my way to become an Elixir programmer. So, thank you all!

Maybe @ericmj might answer you better on how checksums are used on hex. I haven’t browsed the whole code but I think that is a genuine question.

Hi all,

I’m pleased to release version v0.2.0 of Asteroid which brings OpenID Connect support.

It implements:

• OpenID Connect Core 1.0 incorporating errata set 1
• OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1
• OAuth 2.0 Multiple Response Type Encoding Practices
• OAuth 2.0 Form Post Response Mode
• OpenID Connect Discovery 1.0 incorporating errata set 1

It does not implement OpenID Connect logout yet.

Here are 2 videos of how it can look like:

OAuth2 flow:

OpenID Connect flow:

As a reminder, the authentication flow is still a do-it-yourslef thing.

Good news: the bug mentioned in the first post was swiftly fixed by the Erlang team, which means Asteroid will be releasable with the next OTP version.

Next steps:

• Consolidating the AttributeRepository implementations + Ecto / SQL implementation
• Create a project page as suggested by @victorolinasc
• Structured logging
• Authentication workflows: something similar to a form workflow (have been discussed here before) and that would be UI-independant (standard web, REST or LiveView) and some authentication modules (Social Login, MiniPOW, CAPTCHA, WebAuthn, and so on)
• More OAuth2 specifications support: token exchange, resource indicators, pushed request objects…

Anyone wanting to contribute is welcome! The OAuth2 & OpenID Connect ecosystem is super rich and full of specifications to implement, and I’d be glad to help if you wanna join. I have started filling some issues on Github, so if you’re looking for a project to contribute to or if you start with Elixir and want to practice feel free to pick one.

Cheers

Wooo!

Just going to use the traditional delete session token pipeline?

It’s definitely a possibility for simple cases.

When writing this I was thinking of the implementation of OpenID Connect Session Management 1.0 - draft 28 to make it in a standard way. Also, logging out is not so easy because:

• You might want some long-live cookies to remember some information like the accounts having logged in (account selection - in the demo I’ve used LocalStorage but this might not be satisfying) or just for long-lived authentication sessions
• In the actual implementation, the session cookie and the authenticated session (Asteroid.OIDC.AuthenticatedSession) are two different things, so that:
  • one can have several active authenticated sessions in one browser (again, account selection)
  • the session can be destroyed independently of the cookie that might be used somewhere else if Asteroid is embedded in another Elixir app, or maybe some other cases
• there are two additional logout specifications to take into account (OpenID Connect Front-Channel Logout 1.0 and OpenID Connect Back-Channel Logout 1.0). Plus when you logout from website A: should you logout from the OpenID Provider too? Should the OpenID Provider logout the user to all the other sites?

That might be one of the most tricky part of OIDC actually and I dared not touching it at this point

It seems what I am looking! I want to try it right now

is this project under active development and future proof to receive updates?

What do you mean by “future proof to receive updates”?

This project is paused. I’ve been working on it a bit last months but now I’m focusing on Wax (new release soon) and next month I plan to work on a much needed library IMO (code name: Plugoid ).

I plan to start working again on Asteroid in May. If the question is: may I use Asteroid today? I would answer that it’s still version 0.2 and it might be a bit too early. There’s no SQL backend and there’s a lot of rework to do. All of this will probably be done by Q3 this year. But if you’re audacious you can give it a try, I’d be glad to help! Note, however, that it requires OpenID Connect (OIDC) expertise to implement OIDC authentication workflows correctly as of today (there’s no authentication workflow engine yet).

Thanks for the detailed response was looking for this info to consider it.