This project has moved and is read-only. For the latest updates, please go here.

OAuth2 server + FireFox + CORS

Aug 25, 2014 at 4:16 PM
We are using the OAuthAuthorizationServerMiddleware from Microsoft.Owin.Security.OAuth for authorizing an API.

With IE and Chrome, everything is fine.
With FF, the browser does not allow the redirection from the Autorize endpoint (on the OAuth2 server) to the CallbackPath endpoint (on the API server). It seems that FF is more strict on the CORS implementation (302 redirection on AJAX call).

It looks like that the problem comes from the OAuthAuthorizationServerHandler class, on the ApplyResponseGrantAsync method. At the end of each case (Authorization code grant or implicit grant) the handler simply apply a response redirection :
if (_authorizeEndpointRequest.IsAuthorizationCodeGrantType)
{
   ...
   Response.Redirect(location);
}
else if (_authorizeEndpointRequest.IsImplicitGrantType)
{
    ...
   Response.Redirect(appender.ToString());
}
If you look at the CookieMiddleware, it is slightly different :
var redirectContext = new CookieApplyRedirectContext(Context, Options, loginUri);
Options.Provider.ApplyRedirect(redirectContext);
This is the provider that apply the redirect, and in this case, it will transform the 302 redirection into a 200 (see the DefaultBehavior class).

Is it a bug on the OAuth2 server or a volontary missing feature ?
Aug 25, 2014 at 6:38 PM
Edited Aug 25, 2014 at 6:53 PM
Bon allez, je tente une réponse en français (j'ai pas souvent l'occasion de le faire :P)

En deux mots: l'implémentation est bonne et respecte a priori les specs de base d'OAuth2, qui prévoient nécessairement une redirection dans les deux cas:
http://self-issued.info/docs/rfc6749.html#code-authz-resp (via la "query string")
http://self-issued.info/docs/rfc6749.html#implicit-authz-resp (via le "fragment")

Maintenant, ton utilisation de "l'authorization endpoint" - via une requête AJAX si j'ai bien compris - me parait assez surprenante, et plutôt inhabituelle.

Et pour finir: j'avais proposé une modification d'OAuthAuthorizationServerHandler pour permettre de stopper le traitement de la requête et de déléguer la création de la réponse au développeur final mais pas de chance... elle est arrivée trop tard et est passée à l'as. Du coup, pas moyen de réaliser ce que tu souhaiterais via les points d'extensions présents.

Par contre, pas de souci, c'est déjà fixé dans Owin.Security.OpenIdConnect.Server, un fork (expérimental je précise :P) que j'ai lancé avec @manfredsteyer y a quelques temps: https://github.com/AspNet-OpenIdConnect-Server/Owin.Security.OpenIdConnect.Server/blob/dev/src/Owin.Security.OpenIdConnect.Server/OpenIdConnectServerHandler.cs#L353

Si tu veux discuter de ton scénario, n'hésite pas, y a du monde sur JabbR: https://jabbr.net/#/rooms/owin

Edit: au passage, MSFT prévoit de se débarrasser de l'OAuthAuthorizationServerMiddleware dans la prochaine version d'ASP.NET. Et comme il n'y aura plus de mise à jour de Katana à l'avenir, ça veut dire qu'il ne sera pas entretenu. Si tu veux faire un peu de lobbying... c'est par là: https://github.com/aspnet/Security/issues/39#comments
Sep 15, 2014 at 9:47 AM
Pour le moment on a résolu notre problème en réécrivant et ajoutant le point d'extension manquant dans le middleware OAuthAuthorizationServerMiddleware.
Sep 15, 2014 at 9:35 PM
Mais de rien.