Simple authentication and authorization
With the increasing popularity of distributed architectures – particularly microservices – the demand for protocols that enable authentication and authorization is also growing. Sessions and cookies, which were often the tools of choice for traditional Web applications, cannot always meet the requirements for distributed architectures. OAuth 2.0 and OpenID Connect (OIDC) help you to improve the security at your company and allow you to manage passwords for users more easily.
But what can OAuth 2.0 and OpenID Connect do, and how do they differ from each other? What do you need to bear in mind when using these protocols? We’ll show you how you can implement them really easily, what differences there are, and what risks you should and can avoid!
OAuth 2.0 and OpenID Connect fundamentals
There’s a clever way to avoid the tiresome need to constantly contact your technology department or chief information security officer (CISO) and search endlessly for your passwords: OAuth 2.0 and OpenID Connect enable communication between distributed applications in a secured environment, and you only require one password for all of these applications. As well as simplifying password management, this means that you save time and money while your company benefits from extra security.
- OAuth 2.0 allows you to give third parties access to certain data or services.
- OpenID Connect enables the confirmation of the identity of the user for third parties.
Similar enough to cause confusion, yet totally different
We’ve noticed that customers often use OAuth 2.0 and OpenID Connect as synonyms. While the two protocols need each other, they have different tasks:
- OAuth 2.0 is the authorization protocol. It is not intended to pass on identity information. It answers the question “What am I allowed to do as a user?” and handles user authorizations.
- OpenID Connect performs the authorization and asks the question “Who am I?”. To do this, the protocol depicts the identity of the user with the help of ID tokens.
Thus, OpenID Connect enhances OAuth 2.0 with authentication aspects.
You may be asking yourself what this actually means.
Both are standardized protocols that are now already in use at many companies. In comparison with some other approaches, the risk of errors is significantly lower, the efforts for all involved parties are minimal, the protocols are GDPR-compliant, and the availability of frameworks and libraries for various languages greatly facilitates implementation.
This means that with OAuth 2.0 and OpenID Connect, you get a standardized, easy, and safe workflow!
An example – valet parking versus checking into a hotel
- With a normal key, you can unlock and control your car – all functions are possible. If you want to hand your car over for valet parking, you use a second key, to which you can assign certain properties: You only want to make it possible to park the car, without giving anyone access to your trunk or glove box. The personnel can use this key to move your car and park it, but they cannot open your trunk. Furthermore, they remain unaware of your name and identity information, since OAuth 2.0 is not designed to pass on such data.
- However, when you check into a hotel, the staff at reception need to know your identity. In this case, handing over your car key is not enough to get a room key. Personal data must be recorded. In the realm of distributed systems, OpenID Connect is responsible for this authentication.
Challenges during the implementation of OAuth 2.0 and OpenID Connect
Above all, the need for coordination with lots of different players including the data protection officer and specialist departments can make the implementation of OAuth 2.0 and OpenID Connect more difficult. However, problems in understanding what the two protocols can do, and the presence of old or unknown technologies, can pose a major challenge to everyone involved.
The desire for a custom implementation is often high, but such implementations frequently differ greatly from the standard system. In addition, the developers often do not have sufficient technical knowledge, and regulatory requirements of the Federal Financial Supervisory Authority, for example, prevent companies from being more attentive to the possibility of Single Sign-On (SSO) solutions of this kind.
Why are ID tokens so important?
When authorization queries are made, ID tokens pass various identity and authorization information including name, role, and scopes. This is why they are essential for authentication using OpenID Connect. Above all, they are used in distributed architectures and they form the basis for Single Sign-On. As signed JSON Web tokens (JWTs), ID tokens can be checked for validity without a further query and, if necessary, can be passed in encrypted form as per the JWE standard. This makes your user landscape safe and means that users do not need to share their sensitive personal data with other parties. Each user can also use a single password to log onto all applications.
What lies behind Single Sign-On?
That’s good news for all users. Developers have reason to welcome a Single Sign-On (SSO) solution of this kind, too. This is because it allows user data that is entered in dispersed locations in different systems to be collected together to form a single identity – a “federated identity”. This means that the user only has to log on with one identity provider and can then use that logon for lots more services. OAuth 2.0 and OIDC are used to help to define which role has what access to what data.
The advantage is this: The original information always remains in the place where it was entered, since the federated identity ensures uniform data standards, and the information can still be shared if needed.
Improve IT security with OAuth 2.0 and OpenID Connect
Say goodbye to complicated separate solutions and make both the work of your developers and the life of your users easier! Use the widespread open standards OAuth 2.0 and OpenID Connect.
We can help: From identifying the problem to determining requirements, analyzing the current state of affairs, and even performing the entire implementation – we’re your ideal contact partner when it comes to IT security!
In a workshop, we first approximate the requirements that you have for authentication and authorization. We then analyze the current state of your application landscape and system architecture in order to identify problems and further requirements. Finally, we present you with possibilities and solutions that take the determined requirements into account.
- We have a wealth of experience, and we’re happy to advise you on the choice of protocol (OAuth 2.0, OpenID Connect 1.0, replacement of/migration from SAMLv2).
- We can support you and provide manufacturer-neutral advice about the most suitable identity provider for your needs.
- We can check a solution that you have already implemented for compatibility with standards and for security. If we find any anomalies, we’ll be happy to help further.
Have you already decided on OAuth 2.0 or OpenID Connect but aren’t yet sure whether your demands will be met? Are you unwilling to invest a lot of time only to realize that your planned solution isn’t practical?
We can design and implement a technical proof of concept for special scenarios. At a reasonable cost, this demonstrates the feasibility of your project in example form, so that you gain reassurance about implementing your plan.
To avoid raising false expectations: The technical proof of concept developed in this context is not suitable for productive use.
Whether the participants are developers, architects, security officers, or scrum masters: We can explain OAuth 2.0 and OpenID Connect in an on-site training course. The advantage is this: You can let our trainers know about your content requirements in advance so that they can formulate a training course that’s oriented towards your needs.
Nobody enjoys reading the original technical specifications for OAuth 2.0 and OpenID Connect in detail. We are familiar with all of the relevant specifications in these standards along with the most frequent challenges and pitfalls. The content of our training courses can be adapted to provide a management overview for product owners or technical hands-on training for architectures and developers.
Training modules – which can be flexibly combined as desired – include the following topics:
- Introduction to OAuth 2.0 and OpenID Connect
- Authorization grant flows: Which do I use and when?
- What token types exist and how do they differ?
- Token validation
- Implementation of an OAuth 2.0 and OIDC resource server
- Implementation of OAuth 2.0 and OIDC clients (e.g. Angular SPA or Spring MVC)
- Integration of OAuth 2.0 and OIDC in an API gateway
- Advanced concepts such as Token Relay or Token Exchange
- Current developments relating to OAuth 2.0 and OIDC (new security recommendations or best practices)
Are your developers taken up by other projects? We can perform the implementation in your applications for you! Where possible, we use certified libraries for this. The advantage is this: You get proven, safe functions at a manageable cost – so why reinvent the wheel?
We’re available to act as a sparring partner for the implementation process.
With you, we’ll clarify various questions:
- What are all the places where your users have to log on?
- Do OAuth 2.0 and OpenID Connect actually solve your problem?
- Is there already a planned identity provider towards which authentication and authorization are oriented? Have you perhaps already purchased a product? Do you have to provide the product or is it offered by a service provider?
- Do you need a cloud-compatible solution or will the application landscape be operated using your infrastructure?
- Do you already have specific ideas about a target architecture?
- Is integration into an existing architecture required?
- Do other authentication/authorization protocols need to be integrated? Will applications with different authentication/authorization protocols interact with each other?
