This repository contains a Spring Boot 3 project that demonstrates how to secure an API with OAuth 2.0 done using GitHub, but one thing unique about this project is, that we dint use direct GitHub configurations provided by SpringBoot, instead, we tweaked and configured the code to consider GitHub as a custom Authentication/Authorization server.
- Go to GitHub developer portal
- Create a new application and provide the required information
- Set the homepage URL to http://localhost:8080
- Authorization callback URL to http://localhost:8080/login/oauth2/code/gitHubs. (should match the custom registrationId, which is gitHubs)
For App to work with InBuild Github configurations, use the following
spring:
security:
oauth2:
client:
registration:
github:
clientId: {{client-id-here}}
clientSecret: {{client-secret-here}}
For the App to work with Custom Build OAUTH2 configurations, use the following [Here I tweaked the code to assume I'm using a custom Authentication/Authorization Server]
spring:
security:
oauth2:
client:
registration:
gitHubs:
clientId: {{client-id-here}}
clientSecret: {{client-secret-here}}
authorizationGrantType: authorization_code
redirectUri: "http://localhost:8080/login/oauth2/code/gitHubs"
scope: read:user, user:email
clientAuthenticationScheme: form
provider:
gitHubs:
authorizationUri: https://github.com/login/oauth/authorize
tokenUri: https://github.com/login/oauth/access_token
userInfoUri: https://api.github.com/user
userNameAttribute: id
OAuth 2.0 is a framework for delegating access between systems, rather than a comprehensive protocol for authentication or API security. It allows a user to authorize one system to act on their behalf with another system, facilitating data sharing and streamlined experiences. Unlike authentication (proving identity) and authorization (defining permissions), OAuth 2.0 focuses on access delegation. It is intentionally flexible, allowing extensions like OpenID Connect to provide additional functionalities, such as user profile information.
Simply put, it aids in authorization between services. It’s essentially a digital handshake between the app, service, and user, with everyone agreeing on what is shared.
The process generally follows 6 steps with 4 components typically involved:
🔸 Client (app wanting access)
🔸 Resource owner (user)
🔸 Authorization server
🔸 Resource server
To understand the process, let’s take a look at how a game would connect to a player’s Facebook account.
Step 1) Request access: Within the game (client), the player (user) clicks on a “connect with Facebook” button to link their profile and find friends.
Step 2) Redirect to service: The game redirects the player to Facebook’s (service’s) login page.
Step 3) Permission request: After logging in, the data that the game is requesting access to will be shown to the player which they can either allow or deny.
Step 4) Authorization code: If the player gives their approval, Facebook redirects the player back to the game with an authorization code (from authorization server). The code is a temporary credential that proves the player’s consent.
Step 5) Exchange code for token: The game now sends the authorization code along with its own identification to Facebook’s server in the background. Facebook identifies the authorization code and the game’s identity and returns an access token.
Step 6) Use the token: The game can now use the access token to request the agreed-upon data from Facebook (from the resource server), like the player's friends list.
In this process, the player’s Facebook credentials were never shared, but the game was able to access the agreed-upon player data from Facebook. This is what OAuth 2.0 facilitates; allowing third-party applications to access data from services in a secure manner without sharing credentials.
Project to show how to implement OAuth2 login using GitHub/Google/Custom Resource server
Git Reference:
Blog reference:
YouTube: