Donate Donate

Fenrir's aim is to provide a single, efficient and extremely flexible protocol to manage authentication, authorization and encryption in federated environments.

Fenrir is a from-scratch rewrite of transport, authentication, authorization and encryption protocols. The result is an efficient, flexible protocol whose aims are the security and the simplification of both developers' work and the user experience with security.

You can follow news on the development here and on the Fenrir blog

The protocol can handle unicast, Multicast, ordered, unordered, reliable and unreliable transmission, or any combination, with multiple data streams per connection. The federated authentication included grants the interoperability between servers, and introduces the concept of authorization lattice where we can order multiple privilege levels. Finally the whole project does not rely on the certificate authority model, so no X.509 certificates are needed: the keys are derived from DNSSEC.

Check the comparison page for a quick glance.

The whole protocol is designed and developed by Luca Fulchir.

If you need to contact me, just got to #fenrirproject on FreeNode (IRC), use the forum or contact me directly. If you need it, my gpg key id is: F61F6137 (I change it every year)
Full fingerprint: 95EB 6FA4 03D7 29A7 13C2 FC9F F85A DA1C F61F 6137

When ?

Developing is under way. A kickstarter campaign will start soon. I have finished University and am trying to make this project my work.

The library is being developed here. note: rewrite in progress, only the old code is public

It is still incomplete, but I am working towards a demo for now. A stable release might need up to one year.


The development of this project seemed necessary due to the Current Auth schemes status and the Requirements that people are normally searching in an authentication protocol.

I was searching for a new protocol to use in other small projects, I obviously wanted something standard, but with as many features and security as possible.

Transport-wise, If a developers wants to handle multiple streams of data, it has to do it by setting up multiple protocol stacks. This is almost as complex as creating a new protocol, so why reinvent the wheel every time, each time differently?

While searching for the right protocol, I worked on a small implementation of OAuth (v1 and v2) for a university class. On this experience I understood what I was searching for with full details, I had a better view of the various qualities of an authentication protocol and I learned to hate OAuth with a passion.

With these premises I looked better for a little-known protocol or something that met my needs, and I could find none. Fenrir is thus the logical conclusion of my learning and searching: a protocol capable of handling cryptography like SSL/TLS, but with much better support for authentication, authorization and federation . Since I was building a new protocol from scratch, I decided to make it very flexible and to integrate all kinds of stuff, you can check the Comparison page if you just want to have a quick look at how it stacks up to other protocols.


For an technical overview of the protocol read this paper that summarizes the design of the protocol.

For an in-depth analysis of the protocol choices, my master thesis (~80 pages) should give you enough to think about.

This protocol will be UDP-based, much like Google is doing with their QUIC protocol In fact, some ideas were taken from both SCTP and QUIC, so we have a full-featured transport protocol that handles cryptography and authentication in a new way.

The transport layer was redesigned It can now handle Multicast, unicast, reliable, unreliable, ordered, unordered, bytestream and datagream streams. In a single connection and less than 30 bytes. Aside from the transport features, the main objective of Fenrir are cryptography and user management.

To better separate the players in our protocol, we define 4 roles:

  • Authentication Server
  • Service
  • Application
  • Client Manager

The names should be self-explanatory, they are similar to the Kerberos ones, and their function is the same, too.

Separating the 4 roles lets us handle everything that is related to security, authentication and authorization so that the application developers will be able to work completely ignoring things like authentication, authorization, passwords, tokens, encryption, and so on.

Authentication Server

This is obviously the server that will do the authentication and manage the user. This is in constant contact with its Service Servers, to communicate them of new client connections. Ideally there will be one authentication server per domain, and all the services and clients will interact with this for authentication.

Thanks to a couple of tricks, the authentication server will not be able to impersonate its clients on any service.


This is your application server. It may be an HTTP server or anything else. It's in constant communication with the Authentication Server and should NOT have access to the client credentials. This means no user password management either. If your authentication server gets hacked, the data in the services is safe. If your service get hacked, nobody has to change passwords!


The application that the user wants to use (browser/mail client, whatever). The developers of this applications will not have to do anything for authentication, or user management. things will get simpler and more flexible.

Client Manager

The manager for your authentications/authorizations. It will connect to the Authentication server to negotiate the access and crypto stuff to let the application communicate directly with a Service.

This will handle all the security details, so that the application does not need to know anything about handshakes, token, or other authentication stuff.

Ideally one of this will run on every device/user. The authentication server will have a complete view of which devices accessed which service, so that the user will be able to check where its accounts have been used, and even block a whole device without changing many passwords.

More details

If you are interested in the low level details, you can look at the following pages:

For anything more, contact me, I'll be happy to explain.

How can I contribute?

In the next few months the code will change a lot, It will take up until around May for it to stabilize a bit. If the Kickstarter campaign is successful enough, I will hire more developers, so check the status of the campaign if you are interested. A Patreon page might be set up, too.

The library code is public, yet unfinished.

To start coding, please look at the Development page.

Some people might think that there will be problems with software patents. My position on how to deal with those cases is already well defined.