I want to use Okta for authorization and authentication. I will create an Authorization Server which will authenticate people through an IDP.
From what I've read, the authorization server can have custom scopes and scopes are supposed to be the permissions and what something can do.
My question is if a scope can be assigned for a specific user or a group - for example, if I create a scope "can delete from db", can I tell the authorization server to issue me a token for a specific group with that scope and for another group a token without that scope? If it's possible, how do I do it through their api?
Yes, you can use Okta's API access management access policies to assign scopes to users/groups.
In the Admin Console, go to Security > API.
On the Authorization Servers tab, select the name of an authorization server.
Select Access Policies, and then Add Policy.
Enter a Name and a Description for the policy.
Assign the policy to All clients or select The following clients: and enter the name of the Okta OpenID Connect applications that are covered by this access policy. This field auto-completes the names of your OpenID Connect applications as you type.
Create rules based on users/groups and scopes: https://developer.okta.com/docs/guides/customize-authz-server/create-rules-for-policy/#rule-use
yes in okta UI we can do this
But, as per user and group i want to generate token that contains scopes as per user permission like ,
If user 1 is part of ADMIN group then if i login using user 1 's credentials then token should contains ADMIN as value in scope part of JWT token
If user 2 is part of USER group then if i login using user 2 's credentials then token should contains USER as value in scope part of JWT token there should not ADMIN as value in scope in jwt token
I hope u get it
I want those permission value as SCOPE not as CLAIMS
Related
In my Blazor Application, I'm using Keycloak to manage user authentication and authorization. One of the features in my application consists of allowing the users to see a list of all Users Registered in the application. To do that I need to access "realms/realm/users" Keycloak API, but in order to do that I need to get the access token, and to do that I need to pass a 'username' and 'password' to HTTP POST request. How I am supposed to send user's password in request since I don't have access to that? Any thoughts?
My idea was to create a 'bot' user that would have this permission only and get the token for that 'bot' user instead of the actually logged in user, but it doesn't seem right.
I am using an IDP platform (here AWS Cognito but that could be Auth0, OKTA or Keycloak) and I was wondering why I was discouraged to use the ID Token as an authorization token.
To be more specific, I will not make use of a resource server with authorization delegation from a user to a third-party app. My IDP will just let me SSO all my users on my different applications. There is no scope to grant here, only authentication claims that each service will use to grant or refuse access to resources (like an email, user ID, or the roles).
I understand I could provide my application with the id token and then create some session for my user. By why shouldn't I use the id token itself as a stateless session token, given that its signature can be checked on each application's back-end ?
And if I should use an access token over the id token - can I replace scopes by roles ? Or how should I understand the scopes in a non-delegation context ("user is usign the app himself, not giving permission" vs "user is giving all scopes to the SPA front-end which is an application in itself")
By the way, I am recovering the tokens through code PKCE flow on the front end.
The ID token only contains details about the user and how the user authenicated. so its perfect for creating a longer lasting cookie session with the user. The default lifetime for and ID-token is very short as well, like minutes. You typically throw the id-token away after establishing the sesson. You should never ever pass the ID-token around to other services.
The access token is mean to give you access to the APIs that the token is intended for.
when the user signs in, you ask for acceess to certain scopes and the scopes selected (consented) by the user , then is included in the access token (as scopes and audience claims).
In theory you can pass the ID-token to an API, bits not how its supposed to work.
See this and this for more details:
I have a Node.js lambda API that's called by an authenticated user. The user is able to access the API passing a valid JWT token. Now I'd like to interact with Cognito User Pool to change the user's email, password and etc but I haven't figured out how to achieve this using just the JWT.
I've made several tests using amplify-js and amazon-cognito-identity-js
You can reset the user's password by calling an admin API call, not through the JWT token. https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminResetUserPassword.html This will prompt the user for a new password.
This API call is to set a password for that particular user https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminSetUserPassword.html but I prefer the first option.
In order to change user attributes (such as email, birthday...), use https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUpdateUserAttributes.html
So all these are done using the Cognito Service inside the Lambda (not to be confused with the JWT tokens).
I am working on ADFS services for SSO project and was curious to know if we can make adfs to also check roles for authentication not just username and password.
So it will be like for authentication check username password and roles and if user belong to a particular role, he should be authenticated else not.
And I am not sure about it because it should fall under authorization instead of authentication but curious to know if it can be achieved.
I am using OpenIdConnect Protocol and LDAP for user information storage.
Edit 1:
Here an scenario for the problem:
site A(only Admin role user can access):
user provides UserName/Password and user do not belong to admin role(authentication failed and login failed to application).
Site B (Any User can access) :
user provides UserName/Password and user do not belong to admin role(authenticated and logged in to application).
Yes - you can configure ADFS for claims rules and for access policy.
So you can say e.g. that only members with role x can access the application. Or that members with role y can't.
I've stood up an instance of identityserver4, an API project, and a UI.
The workflow is as follows:
User visits the UI.
User provides user name and password to UI.
UI sends credentials to back of web app, which uses a password grant to authenticate the user with IdentityServer4.
IdentityServer4 returns a token.
Token is used to identify who the user is to the UI and that the user has access to certain sections of the site.
When the user needs to do something within the site, the token is passed to the API via bearer auth.
The password grant isn't negotiable, as this is a first party app and it makes no sense to redirect the user away from the main site.
What's the proper set of middleware to use for this? Should I just use a CookieAuthenticationMiddleware and attach the token as a claim? I'll need to access the claims from HttpContext.User claims. Do I need to use IdentityMiddleware?
You can request identity scopes using the password grant type and use the userinfo endpoint to resolve them to claims - like in this sample:
https://github.com/IdentityServer/IdentityServer4.Samples/tree/dev/Clients/src/ConsoleResourceOwnerFlowUserInfo
And yes - you can use the cookie middleware to persist those claims and the access token for later usage.