First draft of Social v2 spec

dogeared commented 7 years ago

To anyone reviewing, you can see what this looks like here, which may be easier than just viewing the diff in the PR.

edjiang commented 7 years ago

This looks great to me! =] Logical extension of what we're doing with Social V2 =]

robertjd commented 7 years ago

Thanks @dogeared !

Assuming this all-in approach on using the Client API (which I think we should do) there are some items that seem to be implied, and I want to enumerate them:

If the client API is disabled, we won't add any social provider links to the view models.
In our default login and registration forms, we're only supporting the authorization code flow, via the Client API. We're not supporting the implicit grant flow anymore (popup approach).
The stormpath.web.social configuration no longer makes sense and should be removed, because the scope value is now found in the view models and the callback value is now the same, regardless of the provider.
For these reasons, I assume these social V2 changes will be a breaking change for all the integrations.

FWIW I think these are the right things to do, I just want to clarify my understanding.

Now, some questions:

Shouldn't the redirect_uri parameter on the request to /authorize always be <web.domainName|current-host-context>/stormpathCallback? This allows us to continue using our general stormpath callback handler to receive the jwtResponse from the Client API redirect.
The options to the /authorize endpoint are enumerated in this doc (scope, state, etc) but do we allow the developer to override those at runtime? How this is achieved would be very framework specific. The state is likely the most useful for a developer.

And now for the big thought.. do we even want to implement all of this as rendered HTML in each framework? It seems like we could save everyone some time by creating a JS widget that gets loaded on /login and /register, this widget would communicate with Client API and dynamically build the form that's needed. This is essentially what @nbarbettini has suggested before and worked on during the hackathon :) We would need to add form field configuration to the Client API feature, but other than that I think this could be a seamless solution that would give the developer a consistent experience and save us a lot of time.

edjiang commented 7 years ago

One of the things in Social Login V2 that went unimplemented (and I'm unsure if it's planned or not anymore) was to do the implicit flow, and return a token directly in the URL as such: /callback#access_token=eyJra....

If that's the case, a JS client (mobile doesn't really care if you can exchange the stormpath_token) would probably want to ask for response_type=token while the backend would want to request response_type=stormpath_token.

In another scenario, the mobile client would want to enumerate the callback URL and change it from what's in the login view model (and we need to get the login view model now, unless we want the devs to hardcode their directory href into the app).

Since enumerating the response_type and account_store_href are the minimum needed to get this flow to work, I think this should be fine. I think I'm going to play it even safer in the mobile apps by overwriting the response_type query parameter every time.

Just a FYI, what's in this proposal is live in the Client API today -- so any changes would need to be accounted for by the JS / Mobile clients.

nbarbettini commented 7 years ago

For these reasons, I assume these social V2 changes will be a breaking change for all the integrations.

That's my assumption as well.

Follow-up question: does this mean that upgrading packages requires both installing a new version of the integration package and enabling the Client API for your application?

It seems like we could save everyone some time by creating a JS widget that gets loaded on /login and /register, this widget would communicate with Client API and dynamically build the form that's needed.

🎉

A very simple approach could be:

<body>
    <div id="login-container">
        <!-- form will be automatically injected here -->
    </div>
</body>

<script src="https://elegant-lynx.apps.dev.stormpath.io/inject/inject-login.js"></script>

The script would load generated HTML via AJAX and inject it into the target div. The HTML should be very simple and expect to be styled by the existing CSS on the page.

As @robertjd pointed out, this means that we'd need to include a way to customize the form fields in the Client API and in IAMUI - not sure if this is planned for Client API yet or not. IMO that would be a very powerful feature.

I'd love to explore this approach more 😄

stormpath / stormpath-framework-spec

First draft of Social v2 spec #132