ueberauth alternatives and similar packages
Based on the "Authentication" category.
Alternatively, view ueberauth alternatives based on common mentions on social networks and blogs.
-
coherence
Coherence is a full featured, configurable authentication system for Phoenix -
phx_gen_auth
An authentication system generator for Phoenix 1.5 applications. -
guardian_db
Guardian DB integration for tracking tokens and ensuring logout cannot be replayed. -
Phauxth
Not actively maintained - Authentication library for Phoenix, and other Plug-based, web applications -
Shield
Shield is an OAuth2 Provider hex package and also a standalone microservice build top of the Phoenix Framework and 'authable' package. -
elixir_auth_google
👤Minimalist Google OAuth Authentication for Elixir Apps. Tested, Documented & Maintained. Setup in 5 mins. 🚀 -
samly
Elixir Plug library to enable SAML 2.0 SP SSO in Phoenix/Plug applications. -
basic_auth
Elixir Plug to easily add HTTP basic authentication to an app -
doorman
Tools to make Plug, and Phoenix authentication simple and flexible. -
ueberauth_identity
A username/password Strategy for Überauth -
Paseto
An Elixir implementation of Paseto (Platform-Agnostic Security Tokens) -
passwordless_auth
A library for simple passwordless authentication -
aeacus
A simple, secure, and highly configurable Elixir identity [username | email | id | etc.]/password authentication module to use with Ecto. -
phoenix_client_ssl
Set of Plugs / Lib to help with SSL Client Auth. -
sigaws
An Elixir library to sign and verify HTTP requests using AWS Signature V4 -
ueberauth_cas
Central Authentication Service strategy for Überauth -
exBankID
exBankID is a simple stateless API-client for the Swedish BankID API -
ueberauth_active_directory
Uberauth strategy for Active Directory authentication. -
zachaeus
An easy to use licensing system, using asymmetric cryptography to generate and validate licenses. -
ex_aws_msk_iam_auth
AWS_MSK_IAM Authentication Plugin for Broadway Kafka
InfluxDB - Power Real-Time Data Analytics at Scale
Do you think we are missing an alternative of ueberauth or a related project?
README
Überauth
An Elixir Authentication System for Plug-based Web Applications
Ueberauth is a two-phase authentication framework that provides a clear API - allowing for many strategies to be created and shared within the community. It is heavily inspired by Omniauth. You could call it a port but it is significantly different in operation - but almost the same concept. Huge hat tip to Intridea.
Ueberauth provides only the initial authentication challenge, (initial OAuth flow, collecting the information from a login form, etc). It does not authenticate each request, that's up to your application. You could issue a token or put the result into a session for your applications needs. Libraries like Guardian can help you with that aspect of authentication.
The two phases are request
and callback
. These phases are implemented by
Strategies.
Strategies
Strategies are plugs that decorate or intercept requests (or both).
Strategies implement the two phases and then may allow the request to flow through to your downstream plugs. Implementing the request and callback phases is optional depending on the strategies requirements. If a strategy does not redirect, the request will be decorated with Ueberauth information and allowed to carry on through the pipeline.
See the full list of the strategies on the Wiki.
Request Phase
The request phase is where you request information about the user. This could
be a redirect to an OAuth2 authorization url or a form for collecting username
and password. The request phase is concerned with only the collection of
information. When a request comes in on the request phase url the relevant
strategy will receive the handle_request!
call.
In some cases (default) the application using Ueberauth is responsible for implementing the request phase. That is, you should set up a route to receive the request phase and provide a form etc. In some cases, like OAuth, the request phase is used to redirect your user to a 3rd party site to fulfill the request.
For example, an OAuth strategy for GitHub will receive the request phase url and stop the request, redirecting you to GitHub’s OAuth challenge url with some query parameters. Once you complete the GitHub OAuth flow, the user will be redirected back to the host site to the callback URL.
Another example is simple email/password authentication. A request is made by
the client to the request phase path and the host application displays a form.
The strategy will likely not do anything with the incoming handle_request!
request and simply pass through to the application. Once the form is completed,
the POST should go to the callback url where it is handled (passwords checked,
users created / authenticated).
Callback Phase
The callback phase is where the fun happens. Once a successful request phase has been completed, the request phase provider (OAuth provider or host site, etc)
should call the callback URL. The strategy will intercept the request via the handle_callback!
. If successful, it should prepare the connection so the Ueberauth.Auth
struct can be created, or set errors to indicate a failure.
See Ueberauth.Strategy
for more information on constructing the Ueberauth.Auth struct.
Looking for an example? Take a look ueberauth/ueberauth_example.
Setup
Add the dependency
# mix.exs
defp deps do
# Add the dependency
[{:ueberauth, "~> 0.7"}]
end
Fetch the dependencies
mix deps.get
Configuring providers
In your configuration file (config/config.exs
) provide a list of the providers you intend to use. For example:
config :ueberauth, Ueberauth,
providers: [
facebook: { Ueberauth.Strategy.Facebook, [ opt1: "value", opts2: "value" ] },
github: { Ueberauth.Strategy.Github, [ opt1: "value", opts2: "value" ] }
]
This will define two providers for you. The general structure of the providers value is:
config :ueberauth, Ueberauth,
providers: [
<provider name>: { <Strategy Module>, [ <strategy options> ] }
]
We use the configuration options for defining these to allow for dependency
injection in different environments. The provider name will be used to construct
request and response paths (by default) but will also be returned in the
Ueberauth.Auth
struct as the provider
field.
Once you've setup your providers, in your router you need to configure the plug to run. The plug should run before your application routes.
In phoenix, plug this module in your controller:
defmodule MyApp.AuthController do
use MyApp.Web, :controller
plug Ueberauth
...
end
Its URL matching is done via pattern matching rather than explicit runtime checks so your strategies will only fire for relevant requests.
Now that you have this, your strategies will intercept relevant requests for each strategy for both request and callback phases. The default urls are (for our Facebook & GitHub example)
# Request phase paths
/auth/facebook
/auth/github
# Callback phase paths
/auth/facebook/callback
/auth/github/callback
Customizing Paths
These paths can be configured on a per strategy basis by setting options on the provider.
Note: These paths are absolute
config :ueberauth, Ueberauth,
base_path: "/login", # default is "/auth"
providers: [
identity: {Ueberauth.Strategies.Identity, [request_path: "/login/identity",
callback_path: "/login/identity/callback"]}
]
Customizing JSON Serializer
Your JSON serializer can be configured depending on what you have installed in your application. Defaults to Jason.
config :ueberauth, Ueberauth,
json_library: Poison # default is Jason
HTTP Methods
By default, all callback URLs are only available via the "GET"
method. You
can override this via options to your strategy.
providers: [
identity: {Ueberauth.Strategies.Identity, [callback_methods: ["POST"]]}
]
Strategy Options
All options that are passed into your strategy are available at runtime to modify the behaviour of the strategy.
Copyright and License
Copyright (c) 2015 Sonny Scroggin
Released under the MIT License, which can be found in the repository in LICENSE
.
*Note that all licence references and agreements mentioned in the ueberauth README section above
are relevant to that project's source code only.