2

We are building a Chrome Extension that will be force-installed on each employee's browser for the companies we work with.

We currently use OAuth but many employees are forgetting to sign up.

We are thinking of replacing OAuth with something that doesn't require employee interaction. One way was setting up per-company API keys. So we'd create a private Chrome Extension for each company with a hard-coded API key in some config, and then use that for each company.

This feels pretty clunky, feels slightly off security wise, and would require a lot of work for us, so I'm curious if there is a better way to do something like this?

cypr
  • 21
  • 1

2 Answers2

1

Kerberos is close to what your are asking. It is fully integrated in Windows (more precisely Windows domain authentication is based on Kerberos), and if fully supported in Linux or any Unix-like because it has existed in the Unix world since the 80'.

All common browsers existing in the Windows world (we tested it with Chrome, Firefox, Edge) allow to automatically send the server a Kerberos ticket corresponding to the domain account.

We already add a SSO solution based on SAML assertions with a central authentication server. We only(*) had to couple that server with the Active Directory Kerberos to have automatic authentication on all our Web applications for all users authenticated in the corporate AD.

(*) not exactly a piece of cake. The entry point was to Google search how to couple a Unix web server on Active Directory authentication. You should find extensive documentation with examples.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
0

What you are really asking is: "Can my app put trust in the authentication system of an external party?" and the answer is absolutely YES

Single Sign-on is one option mentioned in a comment already.

Others are social logins like Google login, and after the user interacts with the 3rd party social website all your app get's is the data/permissions you asked for (if any) and assurance the user authenticated.

There is also the self-managed version of a social login called OpenID Connect (OIDC) where you take more responsibility over the authentication and many other aspects - it is quite complicated and onerous to setup.

Which segue's to Single Sign-on (SSO) equally onerous, because it relies on SAML or something equally enterprisey and also needs you to take a lot of ownership over certain aspects like federated identities

I don't think either SSO or OIDC is what you are after, but maybe SSO is the best choice; try JumpCLoud as a federated identity provider (IdP) (free for 5 users SSO) and if that works, great! If not there are others like Okta/Auth0 and if you are in a cloud each offer their own SSO for a customer to use at a decent cost comparable to the point solutions like Okta/Auth0

Stof
  • 151
  • 9