What is the principle of SSO and the distribution of rights on the example of keycloak?

Question

PHP

Hello. The task is to implement single sign-on technology based on Keycloak. I ask for help to deal with the processing of rights and roles by the application (client). Google did not give a clear idea of ​​​​the logic of work. I would be grateful for any comments.
As I see it simplified:
1. The application (client) sends a request to Keycloak with the id of the client and the credentials of the user who is logging in.
2. In case of correct authorization on the SSO server, the client receives a response in the form of a token, refresh token, and other information. Perhaps among them will be the username of the user, his email, etc., but it seems like this after another request.
3. Further, just the essence of my question - it is not clear what to do with this data, or rather where to manage access to different parts of the application. Let's say the admin role has the right to view the "/users" page, while the guest role does not. Where exactly should the permissions handling for a specific role be: on the backend or specifically on Keycloak? Well, or in some other way.
4. Do I need to somehow save the user who has passed authorization in keycloak to the user table of the application?
Please explain where I think wrong and if not difficult, then how it should be in a couple of words. Thanks in advance)

Answer 1

1. yes, you need to send a request containing the realm, the client id in that realm, and enough data to get the token (for example, grant_type="password", username, password, client_secret)
   
2. yes it gets access_token and refresh_token. You can decode the token and see what is stored in it and pull out the data that you need, for example, roles and username are stored in it, while you can put additional information there
   
3. checking permissions on the back, for simplicity, you are looking for something similar to spring-security, but for php, which will check your token and roles in it, and depending on the role, you will give either 200 or 401 to a request to which the user does not have access
   
4. if you do not need to associate some data of your application with the user ID in keyclock, then you do not need