Hello friendly StackOverflowers,
we are using WSO2 Identity Server 5.6.0 and are trying to use OpenID Connect to secure applications.
I followed https://docs.wso2.com/display/IS560/Configuring+Claims+for+a+Service+Provider and created custom external oidc claims mapping to local claims. I also added the oidc claims to the oidc file in the registry.
It appears though, that the documentation is not fully up to date as there is an additional dropdown in 5.6.0 with the Service Provider Claim Dialect.
When we try to login, the login itself works, but the claims are not attached to the id token correctly. Even though the claim manager was able to retreive the claims, as I see in the logfile.
I tried a couple different variations (Custom Claim Dialects, Local Claim Dialect and also choosing just the Service Provider Claim Dialect), but nothing worked.
Interestingly:
If I choose a claim as the subject, and the consent is given by the user, the claim is attached to the id token - even if I remove it from the subject again.
I managed to get all the claims working, by choosing them as the subject, one by one, and giving consent during the login.
This however only works for this particular user.
Anyone got a pointer to how I have to configure the OpenID claims in 5.6.0? In 5.3.0 they did work with the same configuration.
Regards,
Mat
Related
We are trying to connect a javamail (1.6) client to our office365 mailbox hosted on office365 using OAUTH2 authentication.
No matter what we do, we keep getting A1 NO AUTHENTICATE failed.
We have registered our application with
API Permission
we followed all instructions stated at
https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth
including running the powershell commands to create the principal using the app id and object id, and we granted the app full access to emailbox we want to access.
For authentication we do an HTTP POST as following which generates an access token
This is a client credentials flow with shared secret as explained here
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow
https://login.microsoftonline.com/{our tenant id}/oauth2/v2.0/token
with
client_id=...
client_secret=...
grant_type=client_credentials
scope=https://outlook.office365.com/.default
our javamail configuration
mail.store.protocol="imap"
mail.imap.host="outlook.office365.com"
mail.imap.port="993"
mail.imap.ssl.enable="true"
mail.imap.starttls.enable="true"
mail.imap.auth="true"
mail.imap.auth.mechanisms="XOAUTH2"
mail.imap.user="<email box>"
then in our java code we connect the store with the access token obtained from the above HTTP POST
store.connect(host, user, oauth2_access_token);
We also tried this powershell script, which returns the same error
https://github.com/DanijelkMSFT/ThisandThat/blob/main/Get-IMAPAccessToken.ps1
I do not believe that problem is specific to JavaMail.
It is extremely difficult to determine if an access token has the correct rights or there is something else that prevents the authentication
What else can we try?
Update 1
If we use the powershell script
https://github.com/DanijelkMSFT/ThisandThat/blob/main/Get-IMAPAccessToken.ps1
passing only the client id and the redirectUri the script prompts me for approval and it succeeds
but if we use clientsecret authorization fails
Update 2
I can successfully use javamail with the access token generated by the powershell script.
Clearly the token created with the clientsecret does not have enough rights to access IMAP or the mailbox
I start to wonder if token requests using client secret do not work because our Azure Active Directory has "security defaults" enabled.
May be MFA is enforced therefore any non-interactive requests are blocked
Update 3
https://jwt.ms allows to decode access tokens
The token created with just the clientid (code grant flow) is very different from the one created with the client_secret (client credentials flow).
In token from "code grant interactive" there is an attribute called "scp" Set of Scopes, which lists scopes regardless of what I have in my client app API permission ????
"scp": "IMAP.AccessAsUser.All Mail.Read Mail.Read.All Mail.Read.Shared Mail.ReadBasic User.Read"
The second token from the client credentials flow, has an attribute "roles", but does not have scopes
"roles": ["IMAP.AccessAsApp"]
RESOLVED!
looking at the access token we noticed that the client credentials flow subject (sub) was an id that we did not setup.
Here is the catch: when creating the service principal using powershell in exchange online, for serviceid you have to use the objectid of the enterprise application.
New-ServicePrincipal -AppId {clientid} -ServiceId {enterprise application objectid} -Organization {tenantid}
When creating an app registration Azure AD, you also create an enterprise application
The application object id is different from enterprise application object id.
The client credentials flow uses the enterprise application object id as the user asking for authorization.
The same for granting access to the mailbox using powershell
Add-MailboxPermission -Identity {email} -User -ServiceId {enterprise application objectid} -AccessRights FullAccess
it is unfortunate that the authentication process is so cumbersome
My two cents on this , if you are still facing authentication failure from javamail trying to connect to mailbox and read emails, First and foremost make sure the application setup in azure active directory has below permissions.
IMAP.AccessAsApp
Mail.Read
Mail.Send (For Sending)
Secondly, Create service principal with the enterprise application id as mentioned in the original post.
Once done check here if your generated token has all the roles you have assigned.
Even if you assigned necessary roles and you can able to connect to mailbox via powershell still you might get AUTHENTICATE failed from javamail because you might be using this property (mail.imap.auth.mechanisms) wrongly , replace mail.imap with mail.imaps and it should solve the problem.
"mail.imaps.auth.mechanisms"="XOAUTH2"
"mail.imap.host"="outlookoffice365.com"
"mail.smtp.port"=993
"mail.store.protocol"="imaps"
session.getStore("imaps")
store.connect(host,port,user,token)
Good luck !!
We've populated a test google instance with user data such as externalIds that are unique to our institution - see https://developers.google.com/admin-sdk/directory/v1/reference/users#resource
We have wso2 server 5.4 and are exploring using Google as our IdP. However, we are a bit new to SAML/Oauth/OpenId, etc, and are just beginning to learn about them in depth.
We've successfully connected Google to wso2 as an Identity Provider using Federated Authenticators.
However, when we use that IdP for an SP (saml or oauth), it only returns a default set of information about the user. How can we return more profile information that is stored in Google?
I've been reading about scopes and claims and, etc.. but I'm not connecting the dots so far.
If I populate "customerId" in the Google Directory using their API for all our users, how can I get wso2 to return that information to the SP?
You can use wso2 claim handing to achieve it. When configuring IDP, in the "Basic Claim Configuration" you can enable "Define Custom Claim Dialect". Then add claim map "customerId" to a wso2 local claim(http://wso2.org/claims/userid). In the SP configurations' "Claim Configuration", you have to add that particular claim(http://wso2.org/claims/userid) to the requested claim.
I'm developing a communication flow through Azure AD with OAuth2. So, I'm testing two flows:
- Credentials Flow
- Authorization Code Flow
Everything works fine, except one thing: The Scope/permission (scp) in the Access Token.
When I request an Access Token with the Authorization Code Flow I have a lot of claims and one very important for my business: the scp. This claim has all scopes configured in the Azure portal.
But when I use the Client Credentials Flow this "scp" claim does not return and I can't check if this Access token generated can access an Endpoint in my resource server.
Any idea how to solve this?
the answer to this question explains quite well why it's not working.
Since there is no redirection (there's not user involved) scp claims are not returned. the solution to your problem is to use application roles.
When you get the OAuth2 token using the client_credentials flow, make sure you are passing the resource parameter and populate it with the appId of the application where you added the roles to the manifest.
Have a look at these two links . Looks like you are correct in the client credential flow scp claims are not visible
Getting the access token for Microsoft Graph API
https://joonasw.net/view/defining-permissions-and-roles-in-aad
I am confused about the use of OAuth 2.0 as an Authorization method and OpenID Connect as an Authentication method.
Based on my knowledge OAuth 2.0 is only an Authorization method. In other words, this is the process to request an ACCESS_TOKEN and RECEIVE this ACCESS_TOKEN, like depicted in the image below in yellow ellipse: (simplified)
Before an OAuth 2.0 Client retrieves an ACCESS_TOKEN from an Authorization Server this Server should verify if the User allows it and this is an Authentication Process that OAuth 2.0 does not care about.
When OpenID Connect is included in the mix it allows for an Authentication Method as well, but in my knowledge OpenID Connect just adds a "Claim" in the JWT Token that holds information about user that is using the service, like: email, name and others.
My questions are:
Why not ignore OpenID Connect and just add more "claims" in OAuth
2.0 to get information about users?
Is my description of the flows correct?
OpenID Connect does not merely "add a claim in JWT Token" but:
it introduces a completely new token (id_token) with radically different
semantics than the OAuth 2.0 access_token and a standardized format that is understood by the Client as opposed to the access_token which is opaque to the Client
it "twists" the role of the Client, now becoming the "audience" (or: intended recipient) of a token (i.e. the id_token) whilst the audience of the access_token is still a remote entity (aka. Resource Server) and the Client is only the "presenter" of the latter
The 2nd item is the primary source of confusion between OAuth 2.0 and OpenID Connect.
I don't know if your method will work or not but you're totally free to roll your own authentication. After all, that's what Facebook, GitHub and many others did by customizing oauth2. There ended up being so many oauth2 "authentication" methods that it was never plug and play if you wanted to change your provider. I believe that's why OpenID connect was introduced--a common way of connecting and reasoning about authentication while building on the established oauth2 pattern for authorization. Use OpenID connect or don't...but if you don't you'll be reinventing the wheel.
#sdoxee answers explains thing correctly. But I am adding bit more information for OP's understanding.
These days many identity providers (eg:- Azure AD) issue JWT based access tokens. These JWT access tokens do contain claims about end user as well as JWT related validation details (eg:- Token expiration). Here is the link for Azure AD OAuth 2 success response which highlights access token to be a JWT. Also, see JWT claims to see how they explain the claims. Samples are given below,
family_name : User’s last name or surname. The application can display this value.
given_name : User’s first name. The application can display this value.
One could think of building authentication on claims present in access token, but this is not sticking with protocol. And mostly claims and user information will be implementer specific. Also, by protocol definition, these two tokens (id and access) have two different audiences.
ID token is for client, for validation and for authentication.
Access token is for OAuth 2 protected endpoint.
Again, as #sdoxee highlight, use the correct protocol at correct place. Having claims in access token does not necessarily mean you should use them for authentication.
Hello kind people of the internet.
Does Google OAuth2.0 support an OAuth-flow for a Resource Owner Password Credential Flow?
...and if so, then:
A.) can this type of OAuth flow be tested on the Google OAuth2 Playground?
B.) are there any examples of the "Resource Owner Password Credential Flow" with Google OAuth2.0 and the Google APIs?
Per an OAuth presentation recently in Oslo NDC 2013, this subject flow apparently skips the authorization end point all together and directly talks to the token end point of the OAuth2 server. The request syntax incantation would supposedly look something like this:
grant_type=password&
scope=resource&
user_name=owner&
password=password&
My understanding is the Resource Owner Password Credential Flow is for trusted applications in a back-end enterprise type of situations (where a name-password pair could be securely stored).
This particular OAuth flow would require no end-user consent interaction (no pop-up of a browser to Accept, then get a returned authorization-code, etc). In this subject flow the access & refresh token are directly returned, again: with no end-user interaction (albeit after an entry of a username-password).
Looking through the Google OAuth documentation ( link to Google OAuth2 docs ) there does not seem to be any mention of anything resembling Resource Password Credential Flow, but not sure that necessarily means it is explicitly not supported by Google.
Any help or advice would be much appreciated.
thanks in advance
Dear kind internet person,
it is true that Resource Owner Password Credential Flow is not supported on Google but google suggests you use the Installed Application Flow, which is described in: https://developers.google.com/accounts/docs/OAuth2InstalledApp.
You would need to create an Installed Application in the Google Console (https://code.google.com/apis/console), when you do that you can fetch the client_id and build a GET request with the parameters, which would look like so:
https://accounts.google.com/o/oauth2/auth\?
scope\=<scope>\&
redirect_uri\=urn:ietf:wg:oauth:2.0:oob\&
response_type\=code\&
client_id\=<client_id fetched from google console>
You would construct this URL and navigate to it on your browser, allow access for the app and google would give you what I believe is a code which you can use to get credentials. You can use those credentials to get an access token and refresh it, and this credentials is permanent. There's a good example of that on github. Note that you only need to get those credentials manually once, and then you save those credentials somewhere and keep using them to get/refresh tokens.
Hope this helps!
As far as I know, No. The OAuth 2.0 stuff is for Google accounts, for which Google does authentication.