Is there any way to tell on the client side if a users credentials are invalid? When I intentionally break a users credentials (change username), they are getting an generic error 101 (kPFErrorObjectNotFound). How can I prompt a user to resolve a a legitimate account issue?
I get the security implications of oversharing with error codes, but even a general "something is wrong with authentication" would help. Maybe there's no harm is prompting after error 101, but I'm not when else that error is used.
You could add a cloud function that you call and it checks if it has a user. If the user is correctly logged in then the passed token is converted into a user for the cloud code to access. Your cloud code can then return a simple response code which indicates if the login is valid or not.
Related
We are using Azure AD B2C Custom policies with Microsoft Azure Active Directory to authenticate users. We implemented the password change policy as given in the example below.
https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/main/scenarios/password-change
We created a link the user can visit and change his password. Once the password is changed, the user is redirected to the application again.
However, in some cases, we get the following error when the user is redirected to the application after changing the password.
{
"error": "invalid_grant",
"error_description": "AADB2C90088: The provided grant has not been issued for this endpoint. Actual Value : B2C_1A_Dev_SignupSignin and Expected Value : B2C_1A_Dev_PasswordChange\r\nCorrelation ID: b3a2fdd5-df58-4aa1-8eca-d91503ebb75a\r\nTimestamp: 2022-08-31 12:23:48Z\r\n"
}
This error does not happen to all users. But for some users, it happens always.
We use MSAL Angular library with the following versions.
azure/msal-angular": "^2.1.1"
azure/msal-browser": "^2.22.0"
We appreciate any help to resolve this issue.
I've taken up Widows Samples on Credential Providers and have built one using them as a reference. I'm able to log in seamlessly, wither by giving username and password manually. I've set
CustomCredential::SetSelected (__out BOOL* pbAutoLogon) {
*pbAutoLogon = TRUE; // FALSE;
return S_OK;
}
Now, AutoLogon, when the Tile is selected, is happening seamlessly.
As a test case, I changed the password, and as expected the Login fails. After failure, an error message appears and when I click OK ( this is the only option ), the credentials are resubmitted for a retry. How do can we stop this behavior? Which method gets called after the authentication failure?
I've handled ReportResult() but that did not help.
Thanks in advance.
It's been a while - but I believe GetSerialization() is called to return serialized credentials to LogonUI. You need to implement this as well. The credential provider samples I think have working code for KERB_INTERACTIVE_UNLOCK_LOGON.
You can also change *pbAutoLogon conditionally in SetSelected() - I do this in my credential provider depending on certain results.
ReportResult() would be called after GetSerialization returns its result to LogonUI. Inside ReportResult() you could do things like clear the password box (which is done in the samples code.)
If you're not returning serialized credentials in GetSerialization then I think you might get the kind of error you listed in your original post. In the credential samples KerbInteractiveUnlockLogonPack() is called in GetSerialization() and this is what 'logs' the user in effectively.
The error seems specific - 'the user has not been granted the requested logon type' so maybe it has something to do with the rights of the user you're testing with.
If you are using remote desktop, make sure your users are members of the right groups to be able to login (https://support.jumpdesktop.com/hc/en-us/articles/216424183-General-RDP-You-must-be-granted-the-Allow-log-on-through-the-Terminal-or-Remote-Desktop-Services-Right-) or if it is a regular user that it is allowed interactive login.
Also - SetSelected() Gets called when your credential provider is clicked on - I'm not sure if it gets called after every logon attempt or not (my guess is that it doesn't.) In my credential provider I am using a custom logon dialog that I show using SetSelected().
Starting from the point where an user has given permissions to the app, and the access token is stored in session. Following Google's web server app example, I'm just checking whether an access token exist.
However, the token might expire, or the user might remove it manually on his account page. How do I check that the token is still valid, before executing a request?
Or maybe that approach is wrong, and the correct design includes that I should handle the error after executing the action, and if it's an authorization error then show the user a way to authorize it once again?
The latter is the recommended approach. By assuming failure and dealing with it routinely, your app is much more robust. The only downside is that an access attempt takes a bit longer because of the need to fetch a new Access Token and retry. If that's a problem (it shouldn't be normally), then you can always note the expiration time of the new Access Token and set up a background process to renew it with say 5 minutes to spare.
Using the provided environment and collections from Okta in Postman, I run "Primary Authentication with Trusted Application" and Authenticate with no issues. I then copy and set my SessionToken. When I try to then "Create Session with Session Token" it always fails with:
{
"errorCode": "E0000004",
"errorSummary": "Authentication failed",
"errorLink": "E0000004",
"errorId": "oaeDAJpYgLNQS6AnhFwQ3QLcA",
"errorCauses": []
}
Is there something I am doing wrong? The example Postman call for "Create Session with Session Token" only shows the SessionToken being passed in. I shouldn't need to authenticate again?
Help is appreciated.
It looks like you are doing the right thing here, but please note that you can only call the "Create Session with Session Token" endpoint once. If you call it twice (or more), you will end up with the E000004 error you mentioned.
If you are positive that you only tried this one, instead of copying the sessionToken value you get back from the Primary Authentication call (you can try that one too instead of "Primary Authentication with Trusted Application") into the sessionToken variable, try to copy and paste it directly into the Body of the "Create Session with Session Token" field by replacing the {{sessionToken}} placeholder with your session token value.
Please let me know if that helps!
Removing Postman and starting fresh and following http://developer.okta.com/docs/api/getting_started/api_test_client.html worked for me.
The error code "E0000004" is returned in case of following possible conditions:
Locked out accounts
Invalid credentials
Access denied by a sign-on policy
The errorSummary will be "Authentication failed" only to prevent brute force attacks by not providing much information.
In our application we have been using the "Create Session with Credentials" (which is marked deprecated) which basically looks like:
POST {{url}}/api/v1/sessions
with body:
{
"username": "{{username}}",
"password": "{{password}}"
}
This returns an id which we then use in a Validate Session call any time the user visits another page:
GET {{url}}/api/v1/sessions/{{sessionId}}
This used to work but approximately around 2015-12-15 it stopped working.
Now I get an error like:
{
"errorCode": "E0000006",
"errorSummary": "You do not have permission to perform the requested action",
"errorLink": "E0000006",
"errorId": "oaee2frg7mCRGyp3TE9tgE0Gg",
"errorCauses": []
}
We originally thought it was MFA related but my admin removed me from the AD group that requires MFA and we are still having issues.
So it creates the session fine with my creds (and fails if my password is wrong) but validation of the session fails. I have been testing this with POSTMAN.
Any idea what changed? Are we using this incorrectly?
I'm not able to reproduce the error.
That said, we are moving away from using /sessions for authentication (hence the deprecation as you have mentioned). You should use /authn (http://developer.okta.com/docs/api/resources/authn.html#authentication-operations) to authenticate the user with username/password. You won't get a session created right away like before with /sessions. Instead, you will receive a session token which you can then use to create a session with /sessions (http://developer.okta.com/docs/api/resources/sessions.html#create-session-with-session-token)
The good thing about this new flow (besides a better use of /authn and /sessions) is that you do not need an API key for this. Only a valid set of creds would get you a one-time and short-live session token - which is then immediately used to create the session.