Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

OAuth without reloading the page #448

Closed
zewa666 opened this Issue · 7 comments

3 participants

@zewa666

Hi there,

first of all thx for the awesome work you guys created I love Durandal :)
Ok lets come to my question, I'm pretty new to that whole concept of OAuth/OpenID etc. so I tried to figure out how to embed that into my Single Page Application built with Durandal. The thing I dislike is that it typically requires a page refresh, by using the redirect to the OAuthCallback.

I've seen that nice project DurandalAuth which does some nice work but neither manages to do it without refresh. Additionally I dislike the use of MemberShipProviders because they are somewhat black magic for me :)

After reading some blogs over the net I came up with my own implementation which you can find here.
Its just a demo building upon the Durandal Starter Kit and leveraging Window Popups created via Javascript. After the Popup redirects it calls a function from the calling window to pass the information back to the SPA.

After all it feels like a hack, so I wanted to ask you if there is a better way to achieve this.

@dealproc

I don't think there's a way to do this without either an IFrame or a full page reload/refresh. You are usually in implicit mode, and therefore, need to do it with redirects of some kind.

You could potentially, on your MVC "View" that bootstraps Durandal, take an Access Token from your Identity and/or Authorization Server, embed it as a hidden field, and then as part of the Durandal load, pick that out of the HTML and utilize it... however, I don't know what kind of security implications you may incur.

@zewa666

well my solution with the popup is quite similar to the IFrame scenario, so yeah I didn't find any "redirect-less" way either. But honestly this is not kinda the bigger problem, since as long as the SPA doesn't have to refresh I'm quite fine with it.

The only problem right now is that I'm, as you already mentioned with the MVC View approach, not really aware of any potential security issues doing it this way.

@dealproc

Dependent on your STS Server, I'm wondering if we cannot devise a plan (and/or if it is considered as acceptable by the standards docs.) to have an ability to return a Json or similar document from a controller which contains your access/refresh tokens for use in the system? May want to explore this option, or if you're using Thinktecture Identity Server or Authorization server, ask what the implications are on their issue boards.

@zewa666

Not sure if I properly understand what you mean with your first part. Maybe it's what I'm doing already. Eg. my controllers are like following, were first one issues the request to the Provider, and second is the callback redirected to.

        public ActionResult LoginWithProvider()
        {
            OAuthWebSecurity.RequestAuthentication("Google", Url.Action("AuthentificationCallback"));

            return null;
        }

        public ActionResult AuthentificationCallback()
        {
            AuthenticationResult result = OAuthWebSecurity.VerifyAuthentication();

            if (result.IsSuccessful)
            {
                ViewBag.oauthData = new
                {
                    provider = result.Provider,
                    id = result.ProviderUserId,
                    username = result.UserName
                };
            }
            return View("AuthentificationCallback");
        }

The specific controllerview for the Callback is simply like this, where I just call the callers Function and passing in the JSON resulting.

<script type="text/javascript">
    window.opener.OAuthHandler(@Html.Raw(Json.Encode(ViewBag.oauthData)));
    window.close();
</script>

Exactly this is where I'm not sure whether that's the right way to go or not, because Javascript Window Popups seem like a not so nice thing (not sure if just UI related or also security specific). Also leaving that global Function opens kinda the door for quirky users to exploit the system by calling it themselves.

@dealproc

if you're going to do that, then do the ResourceOwnerPasswordFlow setup, and proceed.

@zewa666

As mentioned I'm pretty new to that whole concept of OAuth but wouldn't the recommended ResourceOwnerPasswordFlow require me to gather the password and login of the user? As far as I understood it's just logging in the user on behalf of them. If so I'd really not wan't to go this way since I'd be responsible for what happens to their credentials.

@EisenbergEffect

Please carry over the confirmation in the google group. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.