In OpenId Connect, if the scope (in the authentication request) is only "openid", could the OpenID Provider skip the consent page ?
It will depend on the OpenID Connect implementation of the authorization server. For example there could be claims that are appended to ID token by default which are not requested in the authorization request scope list (ex:- A user identifier). Thus there could be a consent page displayed from OpenID Connect provider even when scope value is limited to openid.
Rather than when not to show consent page, specification highlight on the scope value offline_access (reference). This scope require prompt parameter consent in authorization request. Thus requiring consent page to be presented to end user.
Related
I'm having trouble understanding how the Principal information is sent in the authentication request to the IDP (e.g. Azure AD) during the SSO authentication process.
I checked the AuthnRequest example shown in this Azure AD article, but it doesn't contain any information about the user that needs to be authenticated:
https://learn.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol
If the user information are not included in the authentication request, can anyone explain to me how the IDP will identify the user in this case?
The AuthnRequest is a browser redirect to the Azure IdP. The Azure IdP doesn't know who the user is either. So it displays an Azure login screen in the browser. The user then logs in to Azure (now Azure knows who the user is) and the Azure IdP redirects the browser to the AssertionConsumerService (ACS) URL of the SP with the SAML AuthnResponse from the IdP identifying the user.
The next time the user's browser is redirected to the Azure IdP by an AuthnRequest, Azure looks at the cookies and knows the user has already authenticated and immediately redirects the browser back to the ACS with the SAML AuthnResponse.
The AttributeStatement in the AuthnResponse identifies the user if the IdP has agreed to release personally identifying information about the user to that SP.
Of course, if the user does not have an account in Azure they cannot login. Azure will know who they are from their login information, which is usually their userPrincipalName, which looks like username#example.com.
As the comment suggests, the username can be in the AuthnRequest but this is not often used. The SP should not ask for the username as the username "belongs" to the user (although ultimately it "belongs" to the IdP) and the IdP may not be willing to release that information to the SP. If the SP doesn't need to know who the user is, just that they have permission to access the service, then username is irrelevant. Permissions are often granted based on the Attribute set in the AttributeStatement and this can be done without the SP ever needing to know the username of the user.
If the SP supports personalisation, such as preferences for a user, not knowing the username isn't an issue. A SAML attribute such as eduPersonTargetedID can be released by the IdP that has the same value for that combination of IdP/SP (to stop cross-service tracking) and the SP can use that to store preferences for the user without ever needing to know the username.
A common way of using SAML is to replace a username/password login screen with the SAML flow:
user goes to https://app.com
app sees the user isn't authenticated (no cookie, session or whatever). This is when a non SAML app displays a login screen.
app redirects user to their IdP. Easy in the case of a single IdP. app does not use Subject in AuthnRequest.
user's IdP displays the login screen for the IdP.
user authenticates at IdP
IdP redirects browser to the app's ACS URL.
app inspects SAMLResponse, looks at the Attribute set and decides whether the user (still possibly anonymous) can get access.
if, e.g. user has an Attribute "eduPersonEntitlement" with a value "http://app.com/entitled" then app creates a session for the user and "logs them in" to app.
when user's session at app expires, app sends them back to their IdP to see if they are still entitled to access the app.
In azure ad portal, after registering the application through enterprise application blade,we assign users and groups for the application .
we can perform single sign on configuration settings where we give
redirect urls , upload saml certificate.
SAML tokens contains information about the user known as claims. A
claim is information that an identity provider states about a user
inside the token they issue for that user. In SAML token, this data
is prsented in \ SAML Attribute Statement.
By default, the Microsoft identity platform issues a SAML token to
your app that contains a NameIdentifier claim having value of the
username ( user principal name) in Azure AD, which can uniquely
identify the user. The SAML token also can contain additional claims
like user’s email address, first name, and last name which can be
configured in a section Attributes and claims , which are included in
token .We can edit this section according to the claims required for
the application about user principal.
References:
SAML 2.0 token claims reference | Microsoft Docs
azure active-directory-saml-claims-customization(github.com)
sample reference:SAML_Token_Configuration
I created an app registration, let's call it API with app id URI = api://dummyapi, with read and write scopes.
On the initial request from another app registration, let's call it client, I got the token after user's consent with token's scp(scope) = "read write" using the below request:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id={client app id}
&response_type=token
&redirect_uri=http://localhost
&scope=api://dummyapi/read api://dummyapi/write
&response_mode=fragment
For future access token requests, is it possible to request a token with only the read scope?
While testing the below request with scope as read only, I get an access token with scp = "read write".
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id={client app id}
&response_type=token
&redirect_uri=http://localhost
&scope=api://dummyapi/read
&response_mode=fragment
I was thinking of a scenario where the UI client app has a readonly and read-write mode, and it can request for a token with scp=read for readonly mode.
Currently, Azure AD will issue an access token with all of the granted delegated permissions for the requested resource, granted on behalf of the signed-in user.
The only exception to this is if the client app dynamically requests permissions, and one of the granted permissions which was not requested were to trigger a conditional access challenge.
(The rest of this answer is just additional details about that exception.)
To better understand this exception, consider an example where an app has been grated User.Read, Mail.Read, and Files.Read.All, and the customer has a conditional access policy requiring multi-factor authentication when accessing mail (but not when accessing files), and the user has not already performed MFA:
If the app requests scope=.default, then conditional access will be enforced, and User.Read, Mail.Read, and Files.Read will be included in the token.
If the app uses scope=User.Read Mail.Read, then again, conditional access will be enforced and again the token will include all three permissions. Note that Files.Read.All was not explicitly requested, but it was granted and including it would not trigger any additional conditional access challenges.
If the app requests scope=User.Read then MFA will not be required, and the token will include only User.Read and Files.Read.All. Note that Mail.Read is not included because it was not explicitly requested and including it would have triggered a conditional access challenge. Also note that Files.Read.All was included, because although it was not explicitly requested, it was granted and including it would not trigger additional challenges.
When I use ROPC (Resource Owner Password Credential) flow in my App to let users to sign in my App, why I cannot see any sign-in logs in AAD with it?
ROPC is defined in OAuth2 protocol: https://www.rfc-editor.org/rfc/rfc6749#section-1.3.3 and it’s not included in OpenID Connect.
It just likes other flows in OAuth2, they’re designed for protecting API resources, not authenticating users.
The behavior of ROPC in AAD:
For the ROPC flow, user inputs his/her AAD username and password in the client app side. Then the client sends the user’s credential to AAD. It shows as this below picture:
This behavior may cause a main risk: The client may store and upload the user’s AAD credential and used it for other things. It can play as a phishing app to obtain user’s AAD credential.
Generally, in claims-based authentication, clients should just obtain a user’s attributes(E.g. claims in OIDC id_token, SAML token) issued by a trusted IDP to identify the user. Client shouldn’t obtain the user’s credential for other Identity providers.
Why it’s still supported in AAD?
We can see lots of our customers want to use ROPC flow to delegate user permissions to run a job automatically. Some of our customers use ROPC for their own customized login experience.
From Microsoft side, AAD supports ROPC flow as we can really understand it’s necessary in some special scenarios.
So, what kind of app we can use ROPC in it?
All client apps should be public client(Native App) first.
In Microsoft 1 party Apps, like Powershell.
In User’s owned/trusted Apps.
How can we avoid being phished by a 3rd party app which prompts AAD login?
Make sure the page prompts you to input your AAD user credential is AAD login page. You can also check the domain in the URL. It should be start with “https://login.microsoftonline.com/”.
Generally, we shouldn’t input the username and password together in one form. If a 3rd party app asks you to input your AAD username and password in one form, you need to be careful and don’t try to login it via your AAD credential here. Because AAD doesn’t provide any login page to let you enter your user credential in one form currently.
Overall, user login via ROPC flow may be a sign-in event for the client but it’s not a sign-in event for AAD as the user is not signed in AAD.
I am building a asp.net webapi which is protected by Azure AD Oauth bearer token authentication. I am using Azure AD Bearer token validation OWIN middle-ware to validate the token and extract the claims.
I have a requirement to differentiate when a request is coming from a service context and when the request coming from user context. I am aware that App Tokens (Issued by AD for a APP context) will not have any UPN claims using which i can easily identify but i was wondering is their any standard way to do this?
Quoting from an internal forum:
The appidacr claim indicates the type of client authentication performed. For a confidential client, the value is 1 when a shared secret (a password) is used as a client secret and 2 when a certificate is used as a client secret. The value 0 indicates a public client, which does not provide a client secret and therefore does not authenticate to the STS. Since confidential clients can acquire both user delegated and app only access tokens, the appidacr claim alone does not help to distinguish a user token from an app-only token.
If you want to distinguish between app-only access tokens, user-delegated access tokens, and id tokens issued by Azure AD (all of which are JWTs signed by the same key), follow this guidance:
First of all, validate the ver claim's value is 1.0.
Next, check to see if the JWT is an access token or an id token. The most reliable way to distinguish between the two is the presence of the appid and appidacr claims. These claims will be present in access tokens, but not id tokens.
If the JWT is an id token, then it represents a user. The subject of an id token issued by Azure AD is always a user. Never accept an id token as proof of authentication, always require an access token.
If the JWT is an access token, the presence of an scp (scope) claim informs you that the token is a user delegated access token. The value of the scp claim tells you what authorization the client has been granted by the user.
If the access token does not have an scp claim, it is an app-only access token. In this case, it may have a roles claim.
Don't rely on UPN and email claims to determine the type of token, they're not as reliable.
Per the Microsoft Docs
Your application may receive tokens on behalf of a user (the usual flow) or directly from an application (through the client credentials flow). These app-only tokens indicate that this call is coming from an application and does not have a user backing it. These tokens are handled largely the same, with some differences:
App-only tokens will not have a scp claim, and may instead have a roles claim. This is where application permission (as opposed to delegated permissions) will be recorded. For more information about delegated and application permissions, see permission and consent in v1.0 and v2.0.
Many human-specific claims will be missing, such as name or upn.
The sub and oid claims will be the same.
Personally in my code, to determine if a token is an App token, I use a combination of checking that the claims: "oid" and "sub" both exist and are the same, as well as checking that the token does not contain a name claim.
In practice I have found that tokens issued using different flows can contain different claims, which is why I have found using a combination of a couple of these properties can lead to better being able to differentiate between a user and application token.
There is now a supported way of telling whether or not the token is for an App or not.
Azure Ad supports the configuring of access tokens, for your protected resource to have some optional claims. The claim needed to answer "Is token for App?" is "idtyp"
See Configuring optional claims for how to set it up
I have been reading about OAuth, and found that
it roughly performs the following
- client sends request token during redirect to server
- Server displays authorization screen to resource owner
- Resource owner provides uid and pw (not passed to client)
- Server sends access token back to client
- clients then users the Access token to gain access to a
resource
Based on my reding it does not appear that OAuth
does not enable SSO or Federation, but on some
Blogs it implies it does perform SSO
Is this correct or incorrect. Can it perform SSO
without the help of other protocols?
Thanks
Yes it supports SSO with this flow.
We have 2 applications A and B.
The user want to access application A
He is redirected to the identity profider (idp)
He logs in with his credentials.
The idp issues an OAUTH token and a cookie
The client now adds the oauth token to the request for app A and is authorized.
When the client wants to access application B he is again redirected to the idp
In this call to the idp the coockie that the idp had returned in the flow with app A is added.
Because of this the idp immediately returns a token for app B, the client does not have to log in again.
The client gan now access app B with the newly created token.
Hope this exmaple flow makes it more clear.