Coffee thoughts on OAuth 2.0 and OpenID Connect
I don’t know, if this really is a good coffee chat topic but it came over my head while I was relishing my evening coffee. I could hear my loud mouthed neighbour whining about a very important office gossip to someone, but yea my geek mind stuck to the topic.
Since the past few years I have been working with lots of people and organisations to understand their needs, designs and goals to adopt web services in their systems. I guide them to adopt RESTful web services which require less development time, less server configuration in compare with big fellow SOAP, and also is easier to maintain.
For OAuth2.0 RESTful web services, supporting libraries and tools are steadily getting better in terms of data security and development support. This is really important because if we start with better, highly secure tools, we would definitely build more reliable software by default.
On the other hand, I have seen a lot of systems out there which are portrayed to be very secure, but leak their application data, user data and unknowingly encourage bad security practise in web applications. I don't want to name them now, but we shall discuss this over another coffee.
I suggest OAuth2.0 framework for the enterprise applications, which is capable of defending the security vulnerabilities, delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. However a bad development practise can make it vulnerable which is off the topic in this note.
OAuth2.0 and OpenID connect are protocols and a standard in which OAuth2.0 is mainly designed for authorization, not for authentication. Which means this protocol is not used to authenticate a user for example in a login page. It is designed for applications that can store confidential information and maintain state. A properly authorized web server application can access an API while the user interacts with the application or after the user has left the application.
You can see the terminologies used in OAuth2.0 and an authentication process diagram in the following picture (token request form yelp.com to Google Accounts to access the user details). I have taken this from my personal journal, apologies for the bad hand writing.
The OpenID Connect ID Token is a signed JSON Web Token (JWT) that is given to the client application alongside the regular OAuth access token. The ID Token contains a set of claims about the authentication session, including an identifier for the user (sub), the identifier for the identity provider who issued the token (iss), and the identifier of the client for which this token was created (aud).
To experiment the possibilities of OAuth2.0, I adopted 'Passport' library in Laravel framework and added a five factor security to the web service in my own terms and it successfully survived my penetration testing, and load testing in JMeter. I have hosted this project in the name of RexAPI and you can visit this link (https://www.rexapi.in/docs) to read my detailed documentation.
So from a developer's perspective the main advantage I see in OAuth2.0 is the reduced complexity. It doesn't really need the request signing process; and it is not really difficult to implement but certainly messy. It reduced the work required to be as a 'client' of web service, which is the pain everyone wants to minimize in modern mobile world.
If your scopes are too broad or your claims include sensitive information or you implement the wrong flow for the environment, the best libraries in the world won't protect you. Your users' information will be compromised, your applications will be vulnerable, and your company will suffer the consequences. Alternatively, if you understand the use cases for your software and what your users are trying to accomplish, your software will be better, more secure, and you can eliminate the 'Kindly accept our apologies..' emails to your customers.
While I complete this writing, I hate my neighbour's newly joined boss, God what a lifeless man he is! Sometimes my geek mind multi-process things which I swear is out of hands :P
Thanks for your time and patience to read this small thought, good day all of you!