OAuth and OpenID Connect in Practice
If you are a developer or an architect working with API development, or front-end development such as Apps or Websites, then this workshop is for you. You don’t need any previous experience with the technologies in order to attend. For the hands-on parts we recommend an intermediate level of computer skills, knowing some programming is helpful but not required to participate.
In short, we will talk about:
- OAuth flows and Actors
- OpenID Connect
- Token Formats
- Token handling
- Securing an API
Bring your laptop!
In this workshop you will be guided through the concepts behind OAuth 2.0 and OpenID Connect. These are emerging standards that will define the way the APIs and apps are built the coming decade. No matter if you are building microservices or monolithic APIs, security and identity will impact your decisions. But implementing an OAuth protected API is not just about reading the specification. During this workshop we will discuss why things are designed the way they are, how they should be deployed in a scalable fashion, and what it means to build an entire platform that uses these standards.
The workshop will introduce you to the concepts and ideas, followed by a practical part where we’ll try out the different flows and where attendees will gain the information needed to implement their OAuth and OpenID Connect based solutions using the Curity Identity Server. During the practical part we will cover the following topics:
- Installing Curity
- In-depth training in the usage of the admin UI to:
- Add profiles (OAuth, authentication, and user management)
- Defining new OAuth client apps
- How to enable OpenID Connect
- Setting up authenticators and chaining them together
- Configuring facilities (like data sources, signing keys, etc.)
- Validating and applying changes
- Overview of the Command Line Interface (CLI) including helpful tips and tricks
- Overview of the REST API (with Postman examples)
The entire workshop will encourage discussions and questions. For example: why should we, or should we not use the standards in certain ways. What can go wrong, and how does your organization gain the highest degree of reusability when deploying these mechanism?
