I am trying to determine the proper way to configurer/modify an account created with WSO2 Carbon, such that the account will return authorization without the need for the user being prompted to explicitly consent.
The accounts are being created programmatically, and the "user" will never know or have the passwords, etc, so I just need the request of authorization to always generate and return a code without rerouting to the authenticate and/or consent pages.
I see that there is a PROMPT parameter that is part of the OAUTH standard, that can be set to NONE, but it says the user must be configured for "pre-configured consent"... so I guess what I am trying to figure out, is how do I set up these users, or identity server, or whatever it is I need to have PRE CONFIGURED CONSENT for the users I am creating?
Try setting SkipUserConsent set to true at repository/conf/identity/identity.xml.
UPDATE
The above will skip the consent page only. Since you need to skip the authentication page also, you can use request path authentication.
Related
I just wanted to get some clarification around this. I'm an Oauth2 rookie, and I'm currently implementing Prompt = "login" into my app which should allow me to enforce re-authentication of the user wherever I choose within my app.
One thing that has me a bit dismayed though is that it doesn't seem like Oauth2 or openidconnect has any specifications for validating that the same user re-authenticated.
For example, say joe#test.com originally signed in and is authenticated into my app. Joe now wants to perform an intimate action within my app but I want him to re-authenticate first. During re-authentication he signs in as Suzy#test.com. There doesn't seem to be an explicit way of enforcing that the new user match the previously authenticated user.
I would love any insight on this snippet.
Thanks all who view!
Ruben
I couldn't find anything built into the framework to handle this. So I ended up persisting the username at the time of issuing the Challenge by adding it to the OIDC State field. I then compare the initial username that's stored in the state with the username that is returned the external IDP provider. If they do not match, I reject the auth request.
How do i get access to the currently authenticated users access token in a Keycloak Service Provider Interface when the user has just logged in?
Current situation:
I am doing a manual Password Grant with Apache HttpClient inside a custom User Federation/Storage Provider when the user is performing a login with username and password.
The users access token is then used to call an internal API with his authentication context. This API call with the users bearer token is required for auditing/GDPR purposes since the user gives multiple consents when logging in.
I am assuming there is no way to get the current users authentication context within a user storage provider since the user is not yet authenticated at that point in time, right?
Is password grant the correct way to obtain a user auth context/token at that time? Another option might be to chain SPIs, e.g. use an Authentication SPI and intercept the token there. But it seems you cannot overwrite an existing Auth flow.
The last and maybe best option would be to create an Event Listener Provider. But do i have access to the access token there?
I would really appreciate some input because this whole endeavour feels a bit off.
Another option (which makes more sense for me) would be to use a client id to authenticate as a service (client authentication), in order to perform the auditing. That way you don't even need the user to be authenticated at that point. I see it as a better solution, since, apart what I have said, auditing is actually a system related chore. If you let any user do auditing, they could script some code with a valid token to perform massive/fake auditings by their own.
It makes more sense to leave it to a concrete client, with a concrete role and request that role for the auditing process.
I'm looking to use an identity service such as Azure B2C, Auth0 or OKTA to secure my application.
After the user signs up for an account, I need to display a custom registration form in my application in order to complete the registration. This form requires a business process behind the scenes and therefore it can't be part of the Identity Service (IDS are quite limited to capturing static data).
How do I ensure the user has completed the registration form on my application, when they sign in?
I'm thinking of using a claim such as "RegistrationComplete" and setting this to False when the user signs up. After they've signed up I can update this claim to be True.
I can't find any information online about this scenario so I not entirely sure its standard best practice.
Disclaimer: I work at Okta
Okta does have some features which should allow this. You can pull properties from the user's profile in Okta and put those properties on tokens as claims when the user is authenticating. So the user profile holds the state you care about. Your app/service can then read this claim from the token to determine if the form should be shown. Once the form is complete, your backend service can use the Okta APIs to update this user profile state, and then send the user through the authorize flow again to get a new token with the updated claim (specifying to not prompt for re-authentication when going through the authorize flow again).
There is a restful provider feature in azure ad b2c. Using the Rest Apis from any service along with custom policies in b2c, we can get user input and save that user input to any database. The REST apis can be used to orchestrate any step.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-rest-api-step-custom
Using the Google Sign In SDK, a user can sign in via OAuth2 with some default scopes requested. It can be beneficial to not request every scope an app may need up front, and instead to request additional scopes at a later time so as to not overwhelm the user at sign up.
Google outlines the process for doing this here.
The issue is that, after a user has signed in with Google, upon requesting additional scopes the user has the ability to switch Google accounts and authorize those scopes using a different account before returning to my application.
Is there a way, similar to calling -[GIDSignIn signIn], to explicitly specify which user I want to signIn and not allow the option of changing accounts?
I am not familiar with Google Sign in SDK. Most of what I have done has been written myself so I don't know how that SDK really works. However that being said the Authentication server does support something called Login_hint which should allow you to force them to use a specific user.
login_hint email address or sub identifier When your application
knows which user it is trying to authenticate, it can provide this
parameter as a hint to the Authentication Server. Passing this hint
will either pre-fill the email box on the sign-in form or select the
proper multi-login session, thereby simplifying the login flow.
More info
login_hint can be the user's email address or the sub string,
which is equivalent to the user's Google ID. If you do not provide a
login_hint and the user is currently logged in, the consent screen
includes a request for approval to release the user’s email address to
your app. (Read more at login_hint.)
If memory services Google Sign in SDK does work with openId connect so it should be possible.
I am using ADALiOS to access OneDrive for business service, and I use below snippet to authenticate a user after account disambiguation,
ADAuthenticationContext *context = ....
[context acquireTokenWithResource:resource
clientId:clientId
redirectUri:redirectUri
promptBehavior:AD_PROMPT_ALWAYS
userId:#"userA#mydomain.example"
extraQueryParameters:#""
completionBlock:^(ADAuthenticationResult *result) {
...
}
The web authentication UI will prompt, and allow user to input credential to continue. The issue here is, in this page, user can also change the user id to userB#mydomain.example, and completion block will be invoked with a error like "Different user was authenticated. Expected userA#mydomain.example, actual userB#mydomain.example. Am I using ADALiOS wrong?
When you specify a userId, ADAL assumes that it was specified because that was truly the user that you wanted. If the resulting user is not the one that was asked for, then you get the error you are seeing. If you don't care which user is authenticated then you can pass nil as the userId parameter and you won't get the error.
The ADAL library does this out of an over abundance of caution. Despite what the userId parameter implies, when you call ADAL there is no way for ADAL to guarantee that you will get a token for the user that you asked for. It will do it's best. If it can find a token for that user in the cache then it will return it. However, as you've seen, if the interactive flow is invoked, nothing prevents the user from entering a different username than the one that was asked for. In that case, a token for a different user will be returned. What happens if the app has associated some UI elements or private resources with a particular userId? If it get's a token for a different user than was asked for, then it might be mixing users in a way that is not obvious to the user of the app. If the user originally signed in as a low privilege user, but subsequently signed in as an admin, and the app doesn't notice this, then bad things may happen. So, the library assumes that if you asked for a specific user, then that is the only user that is acceptable.
What follows is probably more detail than you need but just to be complete I will continue. The userId parameter is unfortunately overloaded for three different purposes.
As a cache lookup key. If ADAL has previously authenticated the passed user, and has a token or refresh token for that user in the cache, then it can look up that token directly and avoid any need for an AAD request. If you only ever authenticate a single user at a time, then this doesn't add any value as ADAL will attempt to find a token valid for the resource that was passed.
As a login hint to the server. The userId is used to prefill the username field as a convenience to the user. However, the user is free to erase that username and provide a different one.
As a hint for home realm discovery. If the user is a federated user, meaning that AAD needs to refer to ADFS (or some other federation server) for authentication, it needs a username to determine the address of the server to which it should refer. Normally this is done via a two step process. The user first lands on an AAD page and types their username. As soon as the username field loses focus the server looks up the username, and if it is a federated user, it starts redirecting them to their ADFS server. Finally, the user lands on the ADFS login page and they find their username already filled in. They enter their password and authentication completes. However, if you pass a userId parameter its value is passed to AAD. As a result, AAD no longer needs to wait for the user to type their username and can send them directly to their federation server, eliminating one page, and allowing the user to go directly to signing in.
If you need 2 or 3, but you don't care about 1 there is a workaround. You can specify nil for the userId but add "login_hint="username" as the extraQueryParameters parameter. Replace "username" with the username you would have passed in the userId parameter. If you do this, then ADAL will be oblivious to the user you have asked for, but AAD will interpret the username as a login hint to prefill the username field, and as a home realm discovery hint. The check to ensure that the user asked for is the user returned will be bypassed. You need to be very aware that you may not get a token for the user you provided as the login_hint. You should ensure that you verify the user before making any assumptions about who they are or what they might have access to.
#Ryan Pangrle is right.
The above work around may not work properly anymore if Microsoft Authenticator is installed.
ADAL has been providing the following API to solve this issue since ADAL 2.1+ :
- (void)acquireTokenWithResource:(NSString*)resource
clientId:(NSString*)clientId
redirectUri:(NSURL*)redirectUri
promptBehavior:(ADPromptBehavior)promptBehavior
userIdentifier:(ADUserIdentifier*)userId
extraQueryParameters:(NSString*)queryParams
completionBlock:(ADAuthenticationCallback)completionBlock;
where developers can set the UPN match to be optional in the (ADUserIdentifier*)userId parameter.