...
Note: Kong validating the refresh token is not yet tested. But since the refresh token from keycloak is of type HS256, and we know the secret to be used to verify the HS256 signature, so we should be able to validate the keycloak token signature in kong also
External systems can obtain a token
Any external system that requires access to API’s, can sigup as an user on Sunbird and then use one of the mentioned flows to generate access token
API access as usual will be on the role of the user account on Sunbird
Any special API access can be granted by Sunbird admin by assigning the appropriate roles on the system
If the system requires user context API’s for other users, then they can authenticate on Sunbird as that user and then use the user specific token for any use cases involved in their end (similar to VDN authentication)
Design discussion that is yet to be done
External systems can obtain a token as anonymous
These are some special scenarios which we need to think
Pure anonymous access with higher rate limit can only be access via Portal / Mobile
For other systems where they need anonymous APIs access, we can expose an open endpoint from where a token will be issued which can be used for anonymous access
These will have very low rate limits to avoid APIs being access unknowingly as telemetry data, streaming url etc, will go unnoticed
This use case should be avoided if possible and APIs / tokens can be accessed / obtained only by signing up as a user on the system
Adding more fine grained roles and Rate Limits
We should have more fine grained roles so we can have ensure a user gets only specific set of APIs and not a wider set of APIs
Additional roles like below can be identified and introduced in the system
ORG_MANAGER
CONTENT_PUBLISHER etc
A possible introduction of redis for storing rate limit values as this will be a true ratelimit, instead of the local pod based rate limits