Single way of authorization for all users of a group

Question

Our organization has a lot of people. And I've a use-cases where I would like to provide a single way of authentication/authorization for all users of a particular group.

Currently, while integrating with third-party services, the employees use the OAuth route (Authorize jira via their official email address). But I think this might pose security risks. What I would like to achieve is to have one single access token which would be shared with all the users. And they would use that access token across all third party integrations.

This way I can configure settings for that specific token. In case, I suspect of any security issues or leakage of our token, I can just revoke that token as an admin.

Is this feasible in the current setup. If so, could you please point me to some documentation pages. Any other suggestions are appreciated.

Chinmaya Patanaik · Answer

Understood. But I'm looking for a feature similar to

* https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html

Another way I was thinking of creating a separate email address (external-integration-jira@dummy.com) and collect it's access token. This token would've limited privileges. Now I'll have an intermediate service where users of our group would authenticate via their official accounts. If successful, I'll use that token to perform various actions on the user's behalf.

I would love to know your thoughts.

Nic Brough -Adaptavist- · Answer

There is no way to do this.

You can't apply rules to people whom you can't distinguish between.  Before you identify someone by having them log in, you can't know what group they are in.

>What I would like to achieve is to have one single access token which would be shared with all the users

That is pretty much the definition of "not secure".  Never never do that.

It is fine to have a generic token that says "you can use this system", but it should never get you any further than "ok, you've got past the basic security, now identify yourself to the system you're trying to get into"

One of my old clients had a system where all of their development systems were completely public.  But if you landed on any of them without the generic SSL certificate installed in your browser, you just get a "nope" web page.  If you do have the right certificate, you then get the login page for some of their sites, or another "nope" if you don't have the second certificate that the organisation has granted to you, the individual.