Allow styling SSO login buttons

[jeremybradbury]

Google wants to be rainbow: https://developers.google.com/identity/branding-guidelines

Twitch wants to be purple: https://developers.google.com/identity/branding-guidelines

Facebook wants you to "continue with Facebook"

Twitter want to "sign in with Twitter"

You get the point. The monochrome treatment is only okay with Discord (since gray is a brand color) AFAIK.

There is another legal/security issue of the logos not leading directly to the third party.

There is a click on a branded logo (that doesn't meet any brand standards) to a url on the directus site /auth/login/twitch before the outbound call.

This violates the OAuth2 standard, which was partly built around brand & legal/copy enforcement of providers, and brand guidelines of many providers... but also around user safety/security.

The user should be able to hover the icon and see they're going to Twitch, when they click on the Twitch icon. Only a "real user click" should trigger the outbound request.

And for example, since Twitch has so many bad/beginner marketing partners, their rules are quite strict. Clicking a link with their logo which leads to your site and url with their name in it, is an implication of partnership in their eyes, even if that page redirects to their site.

To Reproduce

Implement one or many OAuth2 or OpenID solutions

Errors Shown

Monochrome icons are shown violating Third Party brand/logo requirements like Google & Twitch (s).

"Real user clicks" from brand icons do not link directly to the Third Party. The brands allow us to use their logos, when shown in full color and directly linked.

The solution seems two part:

1. choosing a colored icon set, closer to brand OR the actual branded buttons they provide
2. directly linking out from branded buttons

[rijkvanzanten]

The buttons on the login page are configured through the env variables, so there's no requirement to use any specific logo or name.

There is a click on a branded logo (that doesn't meet any brand standards) to a url on the directus site /auth/login/twitch before the outbound call. This violates the OAuth2 standard [...]

Can you link to the spec where this is outlined?

[jeremybradbury]

sure, here is a diagram of the grant process in the RFC.

it outlines how and when you, the resource owner should be contacted.

step A is directly between the client and the authorization server and only contacts you after that step.

https://datatracker.ietf.org/doc/html/rfc6749#section-4.1

[rijkvanzanten]

The provided section in reference doesn't explicitly call out that the link to the provider's login page has to be an tag on a web page:

The authorization code grant type is used to obtain both access
tokens and refresh tokens and is optimized for confidential clients.
Since this is a redirection-based flow, the client must be capable of
interacting with the resource owner's user-agent (typically a web
browser) and capable of receiving incoming requests (via redirection)
from the authorization server.

The only mention of a web site here here is that the user-agent that's used with oauth is typically a web browser, which is also the case in Directus' implementation. If you take the two requirements outlined above, the current flow fits just fine. The client (in this case the Directus API) must be capable of interacting with the resource owner's user-agent (which would be the web browser with the Directus admin app) and capable of receiving incoming requests (which it is, as it's an API).

As a matter of fact, you couldn't even safely do an OAuth2 flow exclusively from just the client-side single page app, as there's no way to safely store the secrets required to make the requests.

[jeremybradbury]

The provided section in reference doesn't explicitly call out that the link to the provider's login page has to be an tag on a web page:

You really like to argue don't you?

Especially about legal stuff that gives ppl reason not to use this product or at least this feature.

You realize we're on the same team here?

Let me break this down really simple for you.

The user agent in our case is a web page loaded from the resource owner which is the server.

The client in this case is the browser/user.

Step A goes from the user agent or web page loaded into our browser directly to the Auth server (id.twitch.tv), then asks the server for permission based on those reaults, then the process continues to token exchange, again direct with Auth server.

What you are doing is inserting the resource owner or server into step A.

As a matter of fact, you couldn't even safely do an OAuth2 flow exclusively from just the client-side single page app, as there's no way to safely store the secrets required to make the requests.

Actually there is, it's called the Implicit Flow, it runs entirely in the browser. It doesn't require a secret because it uses other more secure methods. It's recommended by Twitch when making web apps, and in the documentation specifically states to use an a tag for it.

We don't use this method because we involve servers and game clients. The implicit flow hides all the data from the server using hashes, forcing it to stay between auth server and client.

That all said, if I can't make directus SSO comply with our legal requirements, we can always keep the admin panel email / password and use our own SSO for players & streamers.

Maybe some day you'll follow Third Party rules about branding and links, and even fully comply with oauth2 standards so it can be more widely used.

[benhaynes]

This thread is not feeling constructive any more, so I'm locking it for now. ☮️