This document provides an overview of OpenID Connect, which is a standard protocol for user authentication and authorization. It describes how OpenID Connect provides a secure login mechanism for applications by defining standard APIs for authentication, authorization, single sign-on, and single logout. The document explains the OpenID Connect flow, advantages of using the standard, and security aspects like signed JSON Web Tokens and preventing request tampering. It also discusses solutions built on OpenID Connect and tips for application developers in implementing authentication securely.
3. Building an application
3
● Building user signup
● Building a login/logout mechanism
(authentication and authorization)
● Building reset password / recovery
● Managing users/profiles/sessions.
● The actual app functionality.
5. What do we do wrong?
5
● Either consider security as an afterthought or end
up over-engineering security.
● Baking in authentication and authorization logic
into the app.
● Thinking that people will use the app as we
want.
7. Common mistakes and misconceptions
7
● Trying to implement personally developed
security measures
○ Security loopholes
● Reinventing the wheel.
○ User stores
○ Social Login options
○ Libraries
8. Common mistakes and misconceptions
8
● Not thinking about the user experience
○ Specially user signup
○ MFA
○ Not thinking about single sign on
So what can we do better?
16. OpenID Connect
16
● Provides a standard API for login
○ Request <-> Response
○ A verifiable token containing user identity
(ID Token)
○ An access token that can be used to
obtain further user information
○ Access token also allows scoped
authorization
17. OpenID Connect
17
● Defines a standard mechanism for single logout
● Provides a standard API for client registration
● Provides a standard API for information
discovery
● Build with security in mind.
● Provides an authentication + authorization layer.
19. The OpenID Connect Login
19
Application is registered at the OP (OpenID provider)
1. Send an OpenID Connect Request to OP
2. User is authenticated at the OP
3. User is requested for consent at the OP
4. Application receives an intermediate ‘code’.
5. Application sends the code with the application authentication
information.
6. The application receives an id_token + access token in the
response. App verifies the id_token and completes the login
35. OpenID Connect : Why?
35
● Let’s app and site developers authenticate users
without taking on the responsibility of storing
and managing passwords (Federation)
● End users have control over their data shared
with the app.
36. OpenID Connect : Why?
36
● It’s a well recognized industry standard / API
○ Wide range of OPs to choose from
○ Libraries
○ JSON over HTTP
○ Well tested in terms of security
○ Zero code change solutions available
37. OpenID Connect : Why?
37
● Enables BYOID (Bring your own identity)
● Enables an easy path provide Single Sign On
○ Most IDPs support OpenID Connect
○ Most SaaS apps support OpenID connect
39. OpenID Connect : Security Aspects
39
● Use of signed JWTs to pass user authentication
information
○ App must verify id_token sent in response
● Request objects to prevent request tampering
○ Sending request params in a signed JWT.
● ‘state’ parameter to avoid CSRF token
● ‘nonce’ parameter to avoid replay attacks
48. OpenID Connect in Open Banking
48
● Open Banking Standards are built with data
security and customer consent at their heart.
● Uses OpenID Connect as the authentication and
authorization layer
● Uses OpenID Connect Hybrid Flows to enforce
security
50. Few Tips from one Dev to another
50
● Try to use a standard APIs/solutions for
authentication and authorization.
● Opensource != unsecure
● Use standard libraries.
● Think about how easy it is to migrate from one
vendor to another.
● Think about the user experience (Enabling
BYOID is now becoming a MUST)
51. Credits
51
● All the diagrams I have used in this slide deck
were generously borrowed from various blogs,
websites etc. So the due credit should go to the
respective authors :)