CODEWITHSUNDEEP
pythondjangoauthenticationauthorizationsingle-sign-on
Gmosy Gnaq
Gmosy Gnaq

Reputation: 647

Central Authentication and authorization service

I want to design some "central authentication and authorization service" and I know that there is already a couple. My concerns are not about the standards. In the following lines, I'll try to explain it.

I have created two Django client apps that have their own authentication and authorization mechanics. The two applications have different designs thus different permissions and roles. But the users are identical.

Now I have to create a third application through which the two former applications have to do authentication and that is OK (using for example OAuth). But the third application is also responsible for authorization, i.e. the roles, permissions (including numerous object-level permissions) are stored by and managed in the third application.

The questions are:

  1. How can I implement the third application so that it can support non-specific, free-style permissions?

  2. How can I store those permissions?

  3. How should I transfer the permissions to the client applications?

  4. How can I query for some permissions?

  5. Should I store all permissions in the third application and query for them each time when I the user asks for some resource, or should I save them locally and update them at some points?

I have taken a look at OpenID Connect, SAML, XACML and others. SAML and XACML look promising, But I still confused and the above questions remain unanswered.

I am aware that this question covers a wide area, but having some resources for starting and some example projects will be of great help.

Regards.

Upvotes: 1

Views: 1032

Answers (1)

Putri Karunia
Putri Karunia

Reputation: 449

A possible solution would be like the following:

How can I implement the third application so that it can support non-specific, free-style permissions? Using a JWT Token that includes the user's permissions as scopes.

How can I store those permissions?

  • Store your user Model on the third application, along with the permission/roles for each user.
  • When the user log in, they will be redirected to your third application. On successful authentication, the third application can then generate an access_token in the form of a JWT token which includes the permissions that the user has as scopes.
  • You can then have your front-end include this access_token on API requests to the client applications. The client applications can validate the access_token and check the scopes/permissions for the user to determine if the user can access certain data.

How should I transfer the permissions to the client applications? Your client applications can validate/read the scopes included in the JWT token on each API request

How can I query for some permissions? Not sure what this means, I can interpret 2 different things:

  1. Take Github as an example, a Github App can specify that they need read access and email access (but not the write access), and the user can authenticate and only approve read and email access. In this case, the Authorization Server (Github) would generate a JWT that only includes scopes for read and email even though the user has other permissions available.
  2. If you're talking about the client app wanting to know if the user has certain permission, then it can just look at the scopes included in the JWT. You might need to define the required scope for each endpoint in the client application.

Should I store all permissions in the third application and query for them each time when I the user asks for some resource, or should I save them locally and update them at some points?

The permissions for each user can be stored in the third application, and the client applications just trust the scopes included in the JWT. Since the access_token should be short lived (for example it expires in 1 hour), changes on the user's permission level can be handled by renewing the access_token.

Upvotes: 4

Related Questions