Last post Aug 15, 2019 06:02 PM by mgebhard
Aug 15, 2019 05:32 AM|NewUser2017|LINK
I want to implement a single sign on feature using my own API. Third party application(web application) will call this API and authenticate the users. For the communication between my API and other applications web request will be used. Below is the solution
I provided for this, I have created a API on my application and do the authentication based on request values. After successful authentication, I create the authentication cookie and add it to the response. On the other app I used a HttpWebRequest and create
CookieContainer. Then I get the cookies from response and assign those cookies to Response.
var response = (HttpWebResponse)http.GetResponse();
foreach (Cookie cook in response.Cookies)
Response.Cookies.Add(new System.Web.HttpCookie(cook.Name, cook.Value)
Domain = cook.Domain,
Expires = cook.Expires
In my test environment this works fine since both authentication API and other app are in same domain. But in customer testing phase this does not work due to domain mismatch. Because Authentication API is in different domain.
Is there any way to resolve this issue ?
Aug 15, 2019 10:52 AM|mgebhard|LINK
Is there any way to resolve this issue ?
The code sample is not single sign on. It's cookie authentication. Single sign on flow is different. The client exchanges valid user credentials for a token, usually JWT, from a token service. The client sends the token on each request to access secured
resources. The secured resource knows how to validate the token. The previous is a general overview. You can learn a bit more from the following links.
I recommend Identity Server 4.
Aug 15, 2019 01:02 PM|NewUser2017|LINK
Thanks for the answer.
According to my requirement, my API should be able to authenticate the user. After that third part app need to communicate with my app without sending and authentication details.
So each time third party app communicate with me authentication details are not available. Only at the login API, the authentication details are available.
Is there any way to accomplish this. (without using same domain is there any way to share cookies)
Aug 15, 2019 01:30 PM|mgebhard|LINK
Using a cookie in SSO is clunky at best. The client application must login to fetch the cookie using code. The client application must append the cookie to each HTTP request to a secured resource. From the clients perspective, this is an unusual SSO flow
that does not follow standards. You'll need to explain to the client how to use your custom SSO service. However, if you own both the Client and the Service, you can do whatever you like.
I recommend using standard SSO patterns rather than making up your own. See the links in my previous post.
Aug 15, 2019 01:43 PM|NewUser2017|LINK
I will definitely check the SSO patterns and discuss with my client.
But if the really want to go with cookie how can I fetch the cookies created by my domain to user domain. Is it possible ?
I have some control on client side code as well.
And If I explain my requirement again,
There are two web applications and login details are same for both applications. When user logged in to the application A(client application) it will send a web request to application B(my API). This request will contain encrypted login details. Then application
B will do the authentication and update application A. So at the moment user is still at application A.
And there are multiple operation in application A which will redirect user to application B. If this happen user must automatically logged in to application B. In these redirection login credentials are not provided. (According to their implementation this
is not possible)
Aug 15, 2019 03:21 PM|mgebhard|LINK
Cookie authentication is a pretty straight forward process and relies on a how browser's handle cookies. A browser passes credentials to a URL and if the credentials are valid a token is created an placed inside a cookie and returned to the browser. The
browser will automatically send the cookie to the domain that created the cookie on every request.
Your approach requires a cookie for each domain. Add information in the URL when redirecting form application A to B. Application B will use this information to verify the redirect is validate. Perhaps contact application A and pass the information to
make sure Application A redirected the browser. If the information is validated by application B (and A) then application B will generate an authentication cookie and return the cookie to the browser. At this point the browser has two cookies, one for A
and one for B.
Aug 15, 2019 03:45 PM|NewUser2017|LINK
Aug 15, 2019 06:02 PM|mgebhard|LINK
Hi thanks again<br>
The issue is first time client application(application A) is not able to send a redirect. It will send a web requeat. Application B need to inject the authentication cookie to this web request (HttpWebRequest). And then application A will read this cookie and
add it to browser.<br>
The cookie is available in the web response. But I am not able to add this cooki to browser. The code I add in the initial post is not working.<br>
Any workaround for this issue?
Your approach will not work. I provided a work around above.
You are actually interested in the encrypted token within the cookie. Anyway, the only way to get the token or any bit of information from Application A to Application B is an HTTP GET (redirect) or POST. Application B must/should verify the token.
Your original code appeared to work because the test applications were on the same domain.
Keep in mind that SSO is built on trusting a single source of authentication not multiple.