{"id":6368,"date":"2019-11-27T06:32:42","date_gmt":"2019-11-27T06:32:42","guid":{"rendered":"https:\/\/blogs.aaddevsup.xyz\/?p=6368"},"modified":"2019-12-08T03:19:44","modified_gmt":"2019-12-08T03:19:44","slug":"state-parameter-in-mvc-application","status":"publish","type":"post","link":"https:\/\/blogs.aaddevsup.xyz\/2019\/11\/state-parameter-in-mvc-application\/","title":{"rendered":"How to inject custom data into the \u2018state\u2019 parameter in an OpenID Connect MVC Application"},"content":{"rendered":"

It’s often desirable for an Azure Active Directory (Azure AD)- integrated application to maintain application state when sending request to Azure AD for login. The recommended way to achieve this is to use the ‘state’ parameter as defined in the OpenID Connect standards<\/a>. Also mentioned in our documentation<\/a>, the ‘state’ parameter is used for both preventing cross-site request forgery attacks and to maintain user’s state before authentication request occurs:<\/p>\n

\"\"<\/p>\n

For an ASP.NET or ASP.NET CORE web application using OpenID Connect OWIN middleware<\/a>, the ‘state’ parameter is maintained automatically by the middleware when sending out an authentication request as followed<\/span>.<\/p>\n

GET https:\/\/contoso.b2clogin.com\/contoso.onmicrosoft.com\/oauth2\/v2.0\/authorize?p=b2c_1a_signup_signin
&client_id=<Application ID>
&redirect_uri=<Some redirect URL>
&response_mode=form_post
&response_type=id_token
&scope=openid
&state=OpenIdConnect.AuthenticationProperties%3dgAAAALy6…i<\/span>
&nonce=defaultNonce
<\/span><\/p>\n

\u00a0<\/p>\n

Upon receiving the response from Azure AD, the middleware takes care of validating the ‘state’ parameter to prevent cross-site forgery attack<\/a>. Because this work is done automatically by the middleware framework, this begs the question: How can application developers still utilize this same ‘state’ parameter to maintain user state without compromising the middleware’s security feature?<\/p>\n

The way to do this is\u2026<\/h2>\n

The OpenID Connect OWIN middleware use .Net framework’s Data Protection API<\/a> to encrypt the value stored in the ‘state’ parameter. Thinking along the same line we can use the following code in OpenIdConnectNotifications’s RedirectToIdentityProvider<\/a> event to inject custom data into the ‘state’ parameter:<\/p>\n\n\n

var stateQueryString = notification.ProtocolMessage.State.Split('=');\nvar protectedState = stateQueryString[1];\nvar state = notification.Options.StateDataFormat.Unprotect(protectedState);\nstate.Dictionary.Add(\"MyData\", \"123\");\nnotification.ProtocolMessage.State = stateQueryString[0] + \"=\" + notification.Options.StateDataFormat.Protect(state);\n<\/pre>\n\n\n\n
And we can use the following code to read our custom data back in the AuthenticationFailed<\/a> event, MessageReceived<\/a> event, or at any other relevant place in the code after we receive a response from Azure AD:<\/p>\n\n\n\n
string mycustomparameter;\nvar protectedState = notification.ProtocolMessage.State.Split('=')[1];\nvar state = notification.Options.StateDataFormat.Unprotect(protectedState);\nstate.Dictionary.TryGetValue(\"MyData\", out mycustomparameter);\n<\/pre>\n\n\n\n
Reference:<\/h2>\n\n\n\n
https:\/\/stackoverflow.com\/questions\/37489964\/custom-parameter-with-microsoft-owin-security-openidconnect-and-azuread-v-2-0-en\/37520329#37520329<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
It’s often desirable for an Azure Active Directory (Azure AD)- integrated application to maintain application state when sending request to Azure AD for login. The recommended way to achieve this is to use the ‘state’ parameter as defined in the OpenID Connect standards. Also mentioned in our documentation, the ‘state’ parameter is used for both preventing cross-site request forgery attacks and to maintain user’s state before authentication request occurs: For…<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,5,155],"tags":[171,172,40,145,153],"class_list":["post-6368","post","type-post","status-publish","format-standard","hentry","category-authentication","category-azure-ad","category-oidc","tag-aspnet","tag-aspnetcore","tag-azure-active-directory","tag-azuread","tag-owin"],"_links":{"self":[{"href":"https:\/\/blogs.aaddevsup.xyz\/wp-json\/wp\/v2\/posts\/6368"}],"collection":[{"href":"https:\/\/blogs.aaddevsup.xyz\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.aaddevsup.xyz\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.aaddevsup.xyz\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.aaddevsup.xyz\/wp-json\/wp\/v2\/comments?post=6368"}],"version-history":[{"count":12,"href":"https:\/\/blogs.aaddevsup.xyz\/wp-json\/wp\/v2\/posts\/6368\/revisions"}],"predecessor-version":[{"id":6478,"href":"https:\/\/blogs.aaddevsup.xyz\/wp-json\/wp\/v2\/posts\/6368\/revisions\/6478"}],"wp:attachment":[{"href":"https:\/\/blogs.aaddevsup.xyz\/wp-json\/wp\/v2\/media?parent=6368"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.aaddevsup.xyz\/wp-json\/wp\/v2\/categories?post=6368"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.aaddevsup.xyz\/wp-json\/wp\/v2\/tags?post=6368"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}