Please Explain WebAuthenticationBroker

Question

Too many layers of indirection and it's confusing the heck out of me.

In a normal OAuth, the final leg usually requires a post back to the Relying Party (aka. the server) with the authorization token that will be decrypted later via a public key.

The only example I have seen so far is this:

String FacebookURL = "https://www.facebook.com/dialog/oauth?client_id=" + FacebookClientID.Text + "&redirect_uri=" + Uri.EscapeUriString(FacebookCallbackUrl.Text) + "&scope=read_stream&display=popup&response_type=token";

However it seems like the broker is able to determine if user is legit w/o making a trip to your own server. As indicated by the following line:

if (WebAuthenticationResult.ResponseStatus == WebAuthenticationStatus.Success)

How is that even safe?

1. Shouldn't the server be doing the decryption?
2. For that matter shouldn't your server be initiating the connection? This way it can send some random bits to salt so facebook can secure the return token with?

Is the redirect URI completely arbitrary then, with the broker essentially parsing out the response from the IP (Identity Provider).

Is there some 3rd party server involved in the process eg. MS own server to make this possible that I am not aware of?

If the redirect URI should be a URI that points to my own services, then how do I handle and respond to the request?

Answer 1

The WebAuthenticationBroker is just automating the common technique of looking for a specific URL to navigate to when the authentication is complete and canceling it to extract the access_token. This is mostly used in mobile apps with an embedded browser. There's no server involved (except the Authorization Server).

There are 2 frequently used authentication flows in OAuth2:

1. The authorization code flow
2. The implicit grant flow

In #1 you there are 3 pieces: your server, the authorization server (e.g. Facebook) and the browser. On this flow the access_token is negotiated between your server and the AS, and the browser is an intermediary. (more details are described in this article)

In #2 the access_token is negotiated between the browser (or a browser embedded in a native app) and the AS directly. There are no secrets stored anywhere (as in flow #1). (A summary here)

Your example is using #2 as indicated by the response_type=token

The access_token is typically returned in an URL of the form:

http://{callback}/#access_token={the access token}

When the browser attempts to navigate to this address the WebAuthenticationBroker will interrupt the navigation and call your code. You will then extract the access_token and do whatever your app does with the AS (or your API).

This sample shows how to use it (with our own AS, but you can easily generalize it to any AS).

Note: access_tokens are usually opaque entities. There's no encryption or signature or anything. MOre modern systems will return a Json Web Token, which does have meaning and content and is digitally signed. In the sample above, you will see that in addition an id_token parameter in addition to access_token. That is a JWT.