In Microsoft Azure AD Verifiable Credentials if you try to issue a credential of the same contract URI a second time to the the MS Authenticator wallet it prompts that you already have such a credential.
Is there a flag to allow multiple credentials of a type?
Is it the contract URI that must be unique to not receive the duplicate message?
Currently there is a self imposed limitation in Authenticator to only allow one verifiable credential of a 'credentialType'.
We have a backlog item to remove this limitation. Additionally once we remove the limitation we will also need to give the user the ability to select which VC they want to present when a request would satisfy more than one VC in Wallet. This is the main reason for the current limitation.
Related
In every realm in Keycloak, there is client which often represent the application the user is about to access which is represented as client_id in the url, such as
${keycloak_root_url}/auth/realms/${realm_name}/protocol/openid-connect/auth?response_type=code&client_id=${client_id}&redirect_uri=${redirect_uri}
How do we detect if a user has ever successfully logged in into a particular client at least once?
Out-of-the-box and depending on the type of use-case and client flow used you could either:
Enable the admin events, in particular the Event Type : LOGIN and then query those events for the clientID and id of the user;
If the client in question is using either Browser Flow or Direct Grant Flow then you can (under the Authentication tab) copy and create your own version of one of the flows accordingly. Then add a sub-flow that forces the user to perform an action only during the first login (e.g., accept the 'Terms and Conditions'). Afterwards, under Authentication Flow Overrides (of the client) override the flow with your customized flow, accordingly. Finally, query the user for the first login action required by the client in question.
DISCLAIMER: I am not claiming that those are either the best solutions for this use case or that they are bulletproof.
I am currently developing financial services as a personal project.
In order to strengthen security in the project, it is designed and implemented to process authentication at the gateway stage using AWS API Gateway.
I tried to log in using a mobile phone number and the received authentication number, and I don't think this is appropriate for Cognito and IAM identifiers, so I'm going to run the Node Auth Server that issues and verifies JWT tokens in AWS Lambda.
In the process, I tried to include an identifier such as user_id or uuid in the payload of the JWT token, but my colleague opposed it.
His opinion was that access token should only engage in authentication and that the token should not contain a user identifier.
I agreed with him to some extent, but if so, I wondered how to deliver the user identifier in an API such as "Comment Registration API".
Should we hand over the user identifier along with the access token to the client when login is successful?
in conclusion
Is it logically incorrect to include the user identifier in Access Token's Payload?
If the answer to the above question is yes, how should I deliver the user identifier when login is successful?
I wanted to hear the majority's opinion, so I posted it.
Thank you.
Typically you want enough information in the access token so that you can also do proper authorization about what the user/caller is allowed to do.
Typically, you separate authentication and authorization like the picture below shows:
So, to make an effective API, you do want to avoid having to lookup additional information to be able to determine if you are allowed to access some piece of data or not. So, I typically include the UserID and some other claims/roles in the token, so that I can smoothly let the user in inside the API.
However, adding personal information in the access token might have some GDPR issues, but sometimes it might be necessary to also add. But I don't see any issues adding information like UserId and roles in the token.
Yes it is logically correct and a normal thing to do. To see how to do it in a Node Auth Server, you can look at this: https://auth0.com/blog/complete-guide-to-nodejs-express-user-authentication/
As the title suggests, I'm trying to implement the mechanism of retyping the password again before proceeding any critical action, e.g. change email, deactivate an account, invites a new user, ... etc.
The problem is, I'm confused about how it should be done in the REST world.
Should it be like, first, use the password to authenticate the user, but with a different backing authentication made especially for this action and use the resulted token to access this protected resource later? E.g. a JWT token with a specific claim for this action and guard that endpoint with this custom authentication to authenticate for this custom token?
Or should it be done in one request providing the password and based on password check the action will be proceeded or denied?
Or should it be something else?
Thanks in advance for your help, I really appreciate it.
Note: I'm using DRF that's why I added it's the tag to the question, but as this is a general question
Microsoft provides a variety of windows credential providers referred to as "security support provider" as part of microsoft windows, such as
・password (*1)
・smart card (certificates in window authentication) (*2)
・window hello, PIN (FIDO 2) (*3)
Kerberos is the primary method of authenticating users on Windows for interactive logon using passwords and network logon using Kerberos tickets.
domain user logon process
From using above (*1) or (*2) or (*3), I really want to know is there any simple method to issues (create) kerberos tickets?
I have also consulted microsoft API set about this model (domain user logon process), but there does not seem to be a API to issues (create) ticket kerberos.
The API I have referenced:
SSPI: https://learn.microsoft.com/en-us/windows/win32/api/sspi/
LsaLogonUser: https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-lsalogonuser
Please let me know. Thanks in advance!
Credential Providers are not SSPs; they are Credential Providers. They ferry the credential you're using from the inputs (keyboard, bio, smartcard) to the SSPs. They're not meant to do heavy lifting. The SSPs do the actual protocol work of authenticating to whatever service is your authority.
The image you reference is not technically accurate as that's the pre-Vista process. Everything on the left side of the image is out of date. The right side is still mostly correct.
Color commentary aside, Samson is correct. AD is the ticket creator and the only way you can get it to create a ticket is by requesting it after you've authenticated with a credential, and its for the named credential to a specific named service. The way you request the tickets is through the SSPI ACH and ISC functions. SSPs are the internal implementations of those functions.
LsaLogonUser will verify a credential and store the resultant ticket in a dedicated cache (separate from the default logged on session cache). Often you call CredUIPromptForWindowsCredentials to collect creds, and pass the buffer to LsaLogonUser or the ACH function.
According to the API documentation, /providerAccounts?{providerAccountId} with include=credentials, should return additional credentials information to the linked account for the user.
When testing this call for the sandboxed account, it seems to return the username, but not the password. Is this the expected behavior?
Without a way to obtain the encrypted password (for manual management on user's behalf), we'd be forced to not use FastLink, but rather re-implement the entire Account link logic (pretty much reinventing FastLink from scratch) in order to be able to store credentials for later use. This causes duplicated data, logic, and creates new security concerns with user credentials management.
Yes we return only the username and it is expected behavior.
This is expected behavior of the API. This is done to provide extra level of security to the users of client of Yodlee. What would be your use case where you would need user's credentials apart from account linking done at first place? Apart from that if you are trying to store user credentials, you should not be doing that as that requires a lot of compliance approvals(unless you have those).