I'm trying to write an ASP.NET application that uses the Google Calendar Service. To do so, I'm using the example shown here.
This is a TasksService application, but the methods should be pretty much the same.
It seems though, that this application uses an older version of DotNetOpenAuth, in which the ClientBase interface had a ClientSecret property. In the new version they removed this propery.
Where did this property go?
It is mandatory for the authorization process
The ClientSecret property was replaced with the ClientCredentialApplicator property (and constructor parameter). This gives you the freedom to express not only the secret, but how it should be communicated (via form POST parameter or HTTP Authorization header).
Related
I am writing an OAuth2 client using Qt. For the first stage of authorization, I use qml WebView: a link opens in it, where the user enters data and confirms his actions, after which the google service calls redirect_uri (there is a user scheme like "com.mycompany.myappname://", which I give google when registering an OAuth2 client). Google specifies the result in the parameters in this redirect and sends the authorization code (it looks something like this: "com.mycompany.myappname://?code=4/ABCDEFG&scope=email openid&authuser=1&prompt=consent", where the "code" parameter is used for the following authorization stage - obtaining an access_token). Now, to catch this redirect, I use the Java Activity to which my scheme is attached. Activity reads parameters and sends them to C++ using public static native method. Next, in C++, the second stage of OAuth2 authorization passes.
Question: Is it possible to catch redirect_uri using Qt methods? In order to completely abandon Java and thereby make this client cross-platform for Android and IOS (in IOS, if I'm not mistaken, redirect_uri is also used with the result of the first stage of OAuth2 authorization).
Thanks in advance!
You can use QOAuthHttpServerReplyHandler something like in this official example.
Then the redirect_url might be 127.0.0.1 and then you can handle the payload/url parameters from an appropriate signal from QOAuthHttpServerReplyHandler.
I have configured IdentityServer 3 to use external IdentityProvider which is pointing to AAD.
As of now, when I send a request to IdentityServer, I am properly redirected to the AAD for login, however, the 'state' parameter that I am sending to IdentityServer is overridden, and the value of OpenIdConnect.AuthenticationProperties is encrypted and sent to the AAD as the state in the query string.
For eg:
https://localhost:44333/idpaad/connect/authorize?client_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&redirect_uri=https://localhost:44394/&response_mode=query&response_type=code&scope=openid%20email&state=9b0e82c3-e623-42f1-bede-493243c103e7
Here,
https://localhost:44333/idpaad/connect/authorize -> IdentityServer endpoint
state=9b0e82c3-e623-42f1-bede-493243c103e7 -> client generated GUID sent as querystring.
when I see in the "RedirectToIdentityProvider" middleware in the StartUp.cs of IdentityServer OpenIdConnectAuthenticationNotifications, the value of state is updated to
OpenIdConnect.AuthenticationProperties=(protected values) instead of the GUID and the same is also returned as a query string back to the Redirect URI.
enter image description here
Is there a way to send the original state and not override it by IdentityServer3?
While using wsFederation, I am not getting this issue and the same is forwarded directly to the IdP.
Any help is deeply appreciated.
Most of the time it's advisable for an Azure Active Directory integrated application to maintain an application state when sending request to Azure AD for login. And the recommended way to achieve this is to use the ‘state’ parameter as defined in the OpenID Connect standards.
If you check this document form OpenID, you will find that primary reason for using the state parameter is to mitigate CSRF attacks.
RECOMMENDED. Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie.
The ‘state’ parameter is used for both preventing cross-site request forgery attacks and to maintain user’s state before authentication request occurs.
In an ASP.NET or ASP.NET CORE web application using OpenID Connect OWIN middleware, the ‘state’ parameter is maintained automatically by the middleware when sending out an authentication request, this is the only reason you are seeing the state parameter getting overridden in your case.
But if you want you can add custom data in your state parameter. Use the following code in OpenIdConnectNotifications’s RedirectToIdentityProvider event to inject custom data into the ‘state’ parameter.
var stateQueryString = notification.ProtocolMessage.State.Split('=');
var protectedState = stateQueryString[1];
var state = notification.Options.StateDataFormat.Unprotect(protectedState);
state.Dictionary.Add("MyData","123");
notification.ProtocolMessage.State = stateQueryString[0] + "=" + notification.Options.StateDataFormat.Protect(state);
Check this document and Microsoft identity platform and OpenID Connect protocol for detailed information.
I have a Spring Boot application, that is using Spring Security with OAuth 2.0. Currently, it is operating against an Authentication Server based on Spring Example code. However, running our own Auth Server has always been a short-term target to facilitate development, not a long-term goal. We have been using the authorization_code grant type and would like to continue using that, irrespective of the Auth Server implementation.
I am attempting to make changes to use OAuth 2.0 Endpoints in Azure Active Directory, to behave as our Authentication Server. So far, I have a successful call to the /authorize endpoint. But the call to get the /token fails with an invalid request error. I can see the requests going out.
It appears that parameters that Azure states as mandatory are not being populated in the POST request. Looking at the Azure doco, it expects the client_id to be defined in the body of the message posted to the endpoint, and that is not added, by default, by Spring.
Can anyone point me in the right direction for how I can add fields to the Form Map that is used when constructing the Access Token request? I can see where the AccessTokenRequest object is being setup in OAuth2ClientConfiguration....
#Bean
#Scope(value = "request", proxyMode = ScopedProxyMode.INTERFACES)
protected AccessTokenRequest accessTokenRequest(#Value("#{request.parameterMap}")
Map<String, String[]> parameters, #Value("#{request.getAttribute('currentUri')}")
String currentUri) {
DefaultAccessTokenRequest request = new DefaultAccessTokenRequest(parameters);
request.setCurrentUri(currentUri);
return request;
}
Should I be trying to define the map in a request.parameterMap spring property? If so, I'm not too sure how that works.
Or should I be using one of the interfaces defined in the AuthorizationServerConfigurerAdapter class?
I have the information to include when sending the AccessTokenRequest, I just don't know the best way to configure Spring to include it? Thanks for any help.
Actually, I found this out. I needed to change the client authentication scheme. Simply adding the following to my application properties added the client_id to the form....
security.oauth2.client.clientAuthenticationScheme=form
If you're using yaml, then yaml-ize it. Thank you Spring!
I'm looking at the source code for Microsoft.OWIN.Security.Google and am a bit confused and overwhelmed at how many classes there are to do such a simple thing (redirect, get a cookie, check it).
Can anyone explain how the various components fit together
Middleware
Extensions
etc
... so that I can write a custom provider
After some google-ing and trying different ideas in debugger I ended up with "copy-paste-edit" :)
here is a brief resume of classes
Extensions - nothing special, a helper:
// instead of using
app.Use(typeof(CustomAuthenticationMiddleware), app, options);
// you can use
app.UseCustomAuthentication(options);
Middlware - methods are used to attach authentication to owin pipeline
AuthenticationProvider - As I understand, this could be overriden outside, to be able to change some logic without rewriting whole thing. Has 2 methods:
Authenticated - is called when handler finishes all authentication in AuthenticationHandler.AuthenticateCoreAsync()
ReturnEndpoint which is called in AuthenticationHandler.InvokeAsync, just before external authetication.
But it appeared absolutely useless, when I tried to customize existing providers (google, facebook,...)
Handler - here is all the OAUTH2 functionality.
ApplyResponseChallengeAsync() - generates AuthorizationEndpoint URL and redirects useragent to authorization server
InvokeAsync() - handles the get to RedirectEndpoint (/signin-google or whatever was set up on authorization server) and returns the user to the starting controller(or callback). It is doing a redirect with all needed cookies set up
AuthenticateCoreAsync() - does all server side calls to authorization server. Creates all Identity.Claims necessary to create appropriate cookies before
I am refactoring a working ASP.NET Web Application to expose Web Services interface using ASP.NET Web Service. According to Web Services authentication - best practices, Basic Auth over https is the way to go. Let's assume it is, as opposed to doing WS-Security, X509, etc..
On .NET 3.5/VS 2008, what's the simplest way of implementing custom http Basic Authentication (non-Windows account), for example, accepting only if user name is "foo" and password is "bar". Ultimately, I'd like Thread.CurrentPrincipal set.
Do I write my own HttpModule or can this be done simpler?
Likely using Custom Basic Authentication for IIS, written by Dominick Baier is the way to go. As he points out WCF 3.5's usernames over transport security cannot be used on IIS-hosted service, although my question was regarding ASP.NET Web Services not WCF.
There's another implementation of HTTP Module called Basic authentication in ASP.NET against custom datasource by Santosh Sahoo.
Although it's not what I wanted, I found QuickStart Tutorial's SOAP Headers sample to be informative workaround. Sending password in plain text over http is clearly insecure, but this example could be extended to add more security, for instance running on https or sending hash of "password + one-time GUID + timestamp".
Grab the value of the Authorization header, parse it and validate the username/password.
The value is username:password, encoded as a Base64 string.
See http://en.wikipedia.org/wiki/Basic_access_authentication for details.
Edit: if you want this done for every request, using the custom auth scheme, then it would be easier to write an HttpModule to handle parsing the header and setting the thread's principal.
If you are considering WCF, you can use usernameOverTransport security for basicHttpBinding. i.e. username and passowrd reside in the SOAP header of the request and all the traffic are protected by SSL encryption over the wire.
A custom UserNamePasswordValidator validator can be used to authenticate the incoming credentials against e.g. database.
You can set the thread principal within a custom IAuthorizationPolicy in the service behavior.
e.g. Evaluate method implementation for IAuthorizationPolicy for setting current principal
public bool Evaluate(EvaluationContext evaluationContext, ref object state)
{
Object obj;
if( evaluationContext.Properties.TryGetValue( "Identities", out obj ))
{
// get the authenticated identity
IIdentity client = (obj as IList<IIdentity>)[0];
evaluationContext.Properties["Principal"] = ... // create principal obj here for the identity
// this will set thread's current principal
}
return true;
}