Everywhere for IdentityServer4, redirect_uri contains /signin-oidc as callback after successful authorization.
But as per oidc specifications redirect_uri has no constraint to have signin-oidc suffix.
Is there a way to remove this check or functionality and redirect to what is being supplied as redirect_uri?
Or am I missing something?
I cant understand the purpose of fixing signin-oidc in IDS4 callback
/signin-oidc is just the default path for the .Net OIDC client middleware but it's easily changed via the OpenIdConnectOptions.CallbackPath setting.
Doing so is neccessary if registering multiple schemes of the same type.
Related
I have enabled the Web Application Firewall in the Azure FrontDoor with the default policy with the detection mode.
In the logs generated by the WAF, we can see the firewall is marking the reply url set in AAD with action as Block.
I believe the firewall is detecting this as threat.
Since the url is required for the working of AD authentication, what can be done to ensure the security ?
Or this can be ignored ?
Go to your WAF policy of Front Door WAF policy and click Managed rules. Collapse all and click the related policy and change action to Allow. Then refresh the WAF in front door, it will apply.
You could custom rules for WAF with Azure Front Door and refer to the disable rule in app gateway to fix false positives.
You shouldn't need the reply URL to properly as it's really only required to get the access token. If you're getting the access token and you don't need access to the reply url, this shouldn't be something you need to worry about.
If you would like to get to the reply url for purposes of your application, you could unblock it, but there shouldn't be any security issues assuming you know that the reply url is secure.
Per the docs : https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url
A redirect URI, or reply URL, is the location that the authorization server will send the user to once the app has been successfully authorized, and granted an authorization code or access token. The code or token is contained in the redirect URI or reply token so it's important that you register the correct location as part of the app registration process.
I am using Spring SAML integration. I am getting below error when I tried to SAML logout without SingleLogout point.
I override the SAML method to check metadata has any SingleLogout point or not but it's not working.
Caused by: org.opensaml.saml2.metadata.provider.MetadataProviderException: IDP doesn't contain any SingleLogout endpoints
at org.springframework.security.saml.util.SAMLUtil.getLogoutBinding(SAMLUtil.java:108)
at org.springframework.security.saml.websso.SingleLogoutProfileImpl.sendLogoutRequest(SingleLogoutProfileImpl.java:66)
at org.springframework.security.saml.SAMLLogoutFilter.processLogout(SAMLLogoutFilter.java:140)
To properly override the lack of single logout endpoint in the metadata, you'd have to provide your own implementation of org.springframework.security.saml.websso.SingleLogoutProfile and inject it as a dependency in your application config. Certainly doable but quite a bit of effort for a problem that has a simpler solution: manually modify the metadata you received from the IdP and add the endpoint. (If the metadata is signed, you'll need to remove the signature).
I'm working on a SPA application, and I'm using the recommended implicit flow and I'm able to get access_token and id_token. As I need more than the profile info, I've created a separate endpoint to return the user profile information (along with all the other information that's specific to our business) and this endpoint is protected, and can be accessed only with an access_token as the bearer token. Right after getting access_token in SPA, I call this endpoint to get all the user information (which includes first name, last name etc., that gets displayed on the UI). If there is any problem with the returned id_token and access_token pair, the user profile info endpoint call would fail. So, do I really need to validate the id_token? as I'm not relying on any information within that token.
For authenticating against external login provider or authorization code flow, validating the id_token makes sense, but in my case I'm not sure about it.
According to OpenID spec:
When using the Implicit Flow, the contents of the ID Token MUST be validated in the same manner as for the Authorization Code Flow, as defined in Section 3.1.3.7, with the exception of the differences specified in this section.
1. The Client MUST validate the signature of the ID Token according to JWS [JWS] using the algorithm specified in the alg Header Parameter of the JOSE Header.
2. The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.
Why don't you utilise response_type parameter in authorisation request. By changing its value, you can alter what you receive for authorisation response.
Identity documentation mention about possible response type values. Following is an extraction from their documentation,
As you can see, if you do not want SPA to receive the id token, you can set the response_type value to token. If you do so you will only get an access token, which is enforced by OAuth 2.0 specification. (See the OAuth 2.0's implicit flow response_type explanation from here). Note that when you use response_type=token , you are using OAuth 2.0 (not OIDC)
I don't see any wrong in your approach as long as you utilise features enabled by respective protocols.
I have setup an Application that's is using OKTA as IDP. The app is SAML Based.This part is working fine.
But I am unable to log out. For this we have
1. Enabled Single Logout
2. Set the Single Log out URL (I received this from Metadata of IDP under header Identity Provider Single Logout URL)
3.Sp Issues (I received this from Metadata of IDP under header Identity Provider Issuer )
4. Signature Certificate (This is the certificate of IDP)
Now when I call the Logout URL I am receiving 403. On checking the Logs of OKTA I see the (User Single Sign out from App Failure:- Malformed Request)
Can any one please help me how to fix it.
I am assuming that I just need to call the logout URL and the session will kill off. Is my understanding correct?
Reviving a very old thread, check that you have a ?ReturnTo=<path> at the end of the logout URL.
Okta requires strictly post binding requests for logout. Please make sure you are making POST requests for logout and you are using correct entity Id in request.
I think the setting values below need to be set for sp side.
Set the Single Log out URL
Sp Issues
Signature Certificate
It is not on idp side.
I'm using OIDC with implicit code flow with response type "id_token token". Everything works great but noticed that callback url with access token, id_token, scope and session_state + domain name already contains 2033 characters. Project that I'm working on needs to support IE 10 and as far as I know there is a limit URL 2048 characters. I'm little afraid that length of callback url is apporaching this limit dangerously.
What is suggested approach with cases like that? Could I change response type to "token" and then request user information from user info endpoint? Or maybe should I do something to reduce size of callback url, try to reduce information in access_token and id_token? Third option seems to be reference token but I'm little afraid about overhead with one extra call to STS.
In project I use oidc-client-js and IdentityServer4.
Thanks
Try to keep the token as small as possible. IOW less claims.
IdentityServer removes all additional claims from the identity token by default in scenarios where an access token is available (unless you override this behavior).
Reference tokens are another way of dealing with that as you said. By enabling caching in the API middleware you can keep the overhead small.
IE is the plague.
Similar issue here but with Electron app. Electron app needs to call protected API. API needs to know identity of calling user. I tried changing response type from "id_token token" to "token" but IdentityServer auth attempt now results in :
UI:
Sorry, there was an error : invalid_scope
Debug Output:
Requests for token response type only must include resource scopes, but no identity scopes
Javascript config (borrowed from Dom's great Javascript sample client):
var config = {
authority: "http://localhost:5000",
client_id: "js",
redirect_uri: "http://localhost:5003/callback.html",
response_type: "token",
scope:"openid profile TestApi",
post_logout_redirect_uri : "http://localhost:5003/index.html",
};