Why is SAML for authentication and Oauth is not?

When you use OAuth you are using one sign in (e.g. Facebook or Google) to give permissions to a third party app.

So you still need to sign in there (e.g. to Facebook or Google) as part of that process.

But then they pass a separate token to the third party app which then is authorized to do certain operations (e.g. get your Facebook friends or you Google email account) without that app ever having direct access to the login credentials for the service (e.g. Facebook username and password).

That's why it's used for authorization, not really the same as single sign on, which usually means your company has a list of username and passwords which you keep somewhere and are used to access your company services.  I.e. You expect to sign in using company credentials and not Facebook or Google credentials before accessing your company's services.

If you're happy with people at your company using, say, their Google credentials for accessing everything in your company (which means then everyone in the company MUST have a Gmail or Gsuite account), then you could indeed use OAuth for your apps.

Make sense?

Doug

It does and I thank  you for the explanation I do not fully understand how this applies to adfs...

If adfs can do both where do we draw the line?

Auth would be done by adfs (checking ad, in the end) and at this point the line blurs between SAML and Oauth but everyone suggests to use SAML and I don't get why.

If we'd be using Google Authentication or Facebook I'd totally understand but we'd be using the same facility.

I just need to decide if implement ADFS Oauth or SAML for SSO and the more I read the more I am puzzled.

Te BIG differenceis OAuth is WEB based and uses redirects to go from Service provider -> authentication provider and then return where cookies transfer the trust gained from the authenticationprovider.

With SAML youcontact the Service provider, the service provider contacts the Authenticationprovider and passes on the authentocation data and then acts on the result obtained from the authenticaipn provider.

The big differenceis OAuth works will with HTTP and SAML can be used everywhere if the Service provider can handle it.
OAuth is provided by many large web services (Github,Google, Facebook etc.)   You can also setup an OAuth server for your own services (or allow others to use you service if you allow it).

Hi all and thanks for your kind help.

Doug I think you understood my issue...

I want the users of my application to stop using username / password and be able to use their windows credentials transparently when they open my web application.

Can this be implemented only with SAML or with both, given the fact that ADFS is the facility that will take care of the authentication part?

If we're talking about a web app - then yes I think that could use OAuth to handle the authorization to use your app via ADFS.

Check this page out - it may help:
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/development/single-page-application-with-ad-fs

Is this your use case?

Doug

P.S. I work on the Linux side of things so don't really know much about the details of ADFS but I do get the general concepts for OAuth.

Thanks for your help!

The result I'd like to obtain is "automatic" and transparent login (or re-login if token is expired).

When the user opens the page his / her login process should be fully automated and relying on the windows user.

Sorry I think I forgot to mention this requirement before!

How long the tokens are valid for should be a function of how the authentication server (ADFS in this case) is configured.
If you control the server, presumably you can give the tokens an infinite lifetime.

As for whether you can establish the initial login without the user granting access to their account info or otherwise signing in, that seems like it would be a security issue.  A website (browser) shouldn't be able to silently access the logged in Windows user without their knowledge/permission - which generally means them signing into something.

While I do understand your concern about automatic logins security is not an issue here because we are just talking about intranet and the windows login is indeed secure.

It may be sufficient to "kerberize" (use kerberos ticketing) in your applications.
Kerberos is the underlying authenticationprotocol.  That will make the app request an new ticket with the central server.

I didn't mean I'd be worried about security, it's just the browser manufacturers would be.  It's the same reason that web apps can't access the local disk.

Anyway I've personally never seen this style of OAuth in a web app where the sign-in wasn't presented in some manner to the end user.  So it may be possible to get this auto login to work, it's just not something I've personally seen.