I really wish that OIDC / Oauth(orization) would be less confusing from user experience and security perspective.
What I have in mind - I'd say only very small population understand that OIDC / Oauth(orization) is about granting access to a service to access your data. Meaning once you have approved service (lets say Dropbox), now Dropbox can access your data on your google account (this of course depends what exactly dropbox asked and if you clicked on "approve", but most people do click as they want to login to Dropbox via their Google account).
SAML is better, as it can be defined at Google side what data is being sent to DropBox when Single Sign On happens and DropBox cannot access your google data as it sees fit.
SAML ain't perfect either because there's no practical way to "sign me out everywhere"
Interesting. For example how would one find a "new" Tool or Deftones? Current algorithms probably don't "pick up" not-yet-so-popular things. For example Shelton San (I found out about them via word-of-mouth), although I'm frequent user of Spotify.
This means that classical promotion channels are still necessary, as otherwise things get lost in noise.
I noticed that Spotify surfaces similar artists who are also of a similar popularity. So it's not like it doesn't understand that particular style, it just has to somehow pick a couple of dozen artists to show in that very coveted spot.
So what worked for me in the past is finding less popular artists and then checking their similar artists.
This sounds like a complaint with Google's implementation, not with OAuth in general. The correct scopes should limit information sharing to the user's profile. All of the security and privacy concerns that necessitate an explicit user interaction apply to SAML too.
That's the thing - authentication capability is basically sideeffect of Oauth/OIDC.
SAAS x can request whatever they want via OIDC and then user can either accept it or decline it. This is protocol, not google specific matter. Ask ordinary user how they understand what is being asked from them when they are trying "to log in" via OIDC/Oauth.
With SAML it's the other way around - administrator chooses what is being sent to SAAS x, user does not need to decide anything nor do they get hard to understand prompts.
I'd say the main difference is that OAuth is granting the SP the ability to "do stuff" as the original user (including reading the user's profile details, as OIDC does), as opposed to SAML's approach of just sending attributes describing them.
For what it's worth, it is certainly possible for SAML SPs to flag that certain attributes should/must be released to them via their metadata, but the actual release is at the whim of the IdP and its operators. It's also possible for a SAML IdP to expose that level of detail to its end users and allow them to agree/disagree to the attribute release, although I'd be surprised if that behaviour was particularly common in practice.
The difference between OIDC and OAuth boils down to exchanging attribute assertions describing a user as opposed to the delegation of a specific set of allowed actions, as OAuth was intended to do. OIDC and SAML are basically the same thing, with OIDC being a somewhat less frightening and more modern protocol.
Reading the user's profile information _is_ the delegated action. OAuth providers were already doing this prior to OIDC but in incompatible ways. OIDC standardized how that information is requested and returned.
Should, but don't. OAuth2/OIDC implementations tend to be way more transparent about the asks being made between an IdP and SP. It can be confusing. (I agree, however, it's the right path.)
You can't compare OAuth with SAML. OAuth is authorization and comes only ever after authentication, which is OIDC.
But to respond to your critic: It is good that apps let you know that you are IN FACT not merely logging into something, but grant that app access to your Google Drive. This is a very important information! Imagine your mom signs into ClashOfClangs (a malicious clone) and the IdP would in fact NOT tell your mom that the app will have access to all her files because it may be confusing
Would be great if chromeos flex would start supporting organisation provided wifi credentials - currently only device generated keys are an option, meaning one has no idea whatsoever if keys generated are actually good enough or are just looking random while generated might be generated predictably. No idea, as it's a black box. Allow organisations to generate keys off device and allow these to be uploaded to the device, and then we can start considering it.
The other problem is that other vendors do not provide chromeos versions of their tools. Looking at you Fortinet and your vpn.
When has the switch been toggled though and how can I know in each implementation?
1. Is it when I pushed the toggle, regardless of when animation finishes?
2. Is it when the animation finishes
This is necessary when flipping many toggles on one page and it needs to be done many times over. In case there's no animation, it simple and clear. In case there's animation you need the know is it case 1 or 2. If it's case 2 it will additionally slow you down as you now need to wait until all animations lengths * number of switches toggled has finished.
Looked very promising, but there are some hard blockers:
1. It's not shipping yet, meaning there are no trustworthy reviews.
2. It will be shipped to USA only.
3. It needs apple device for (full) control.
That’s why I originally replaced the hub. But it’s a much better hub on its own so I’m not too mad. I can’t find matter devices independently that I want to use and are actually working properly.
What I have in mind - I'd say only very small population understand that OIDC / Oauth(orization) is about granting access to a service to access your data. Meaning once you have approved service (lets say Dropbox), now Dropbox can access your data on your google account (this of course depends what exactly dropbox asked and if you clicked on "approve", but most people do click as they want to login to Dropbox via their Google account).
SAML is better, as it can be defined at Google side what data is being sent to DropBox when Single Sign On happens and DropBox cannot access your google data as it sees fit.
SAML ain't perfect either because there's no practical way to "sign me out everywhere"