Recommended reading - change authorization to preffered method OAUTH2

What is the support strategy for the old auth method (using http://{env}, will there be an end-of-life?

Av: Matthijs Wagemakers 3. des 2018

We have not seriously discussed end-of-life for the old form yet.

That said, there are benefits to changing the install/sign-in URL, which is very simple, so here are a couple defining factors toi consider:

First is the structure and result of each form:

The main difference is that in the old form you get back a user ticket. In the OAuth form you get back an access_token. Both used for the same thing, but note that the user ticket claim is NOT included in the OAuth form result - it's irrelevant.

Second thing is the SSO experience. As seen in the updated Security and Authentication article:

Hosting Applications in Superoffice

There are cases where, in the SuperID user repository,  a single individual has one user account associated with multiple online installations.

Under those circumstances, after successfully authenticated, the user is presented with a selection of installations to navigate to. 

Under some circumstances this is the prefered behavior, however, in the case where an application is hosted in a SuperOffice Web Panel; and therefore inside a known tenant, having a true single sign-on (SSO) experience is the preferred flow. 


In that case, where the application is hosted inside a SuperOffice web panel and the user should have a true SSO experience, change the applications OAuth 2.0 endpoints to include the tenants customer identifier to bypass the tenant selection screen.

That means instead of using the following generic endpoint:

In the web panel's URL, use the <uctx> template variable to get the customers context identifier and include that in the endpoint.{contextIdentifier}/oauth/authorize

// example

This will ensure the web panel application provides the user with seamless SSO experience.


These are the key differences. 

I think the biggest thing holding us back, up until EW2018, was that the SuperOffice proxies did not support an access_token as a valid authentication type. Now, since v8.4 R03 (8.4.6883.1105), the proxies support authentication with access tokens. 

// SoAccessTokenSecurityToken REQUIRES Services86 or higher!!!

using (var session = SoSession.Authenticate(
    new SuperOffice.Security.Principal.SoAccessTokenSecurityToken(result.AccessToken)))
    var principal = session.Principal;
    // do stuff...

Best regards


Av: Tony Yates 3. des 2018