I cannot speak for the duality or not of using OIDC/PAT, but I just wanted to let you know the high level usage of PAT vs the old OIDC method.
Using OIDC, you needed to make an authentication call using OAuth2 to generate a bearer token. This bearer token was then used in the subsequent calls to any of the OneStream Endpoints. So basically, a two step approach.
Using PAT, you now already HAVE the bearer token (which is the PAT token), so only the second step of the above process is needed, call the OneStream endpoints directly and use the PAT token in place of where you previously used the bearer token. So if anything, using PAT is much more consistent as you always talk just to the OneStream endpoints themselves, no need for the extra Authentication call first.
Hope this alleviates some of the painpoints you are referring to above?
I understand the popularity of PAT tokens, given that they are quick-and-dirty. They are suitable to most of the users of onestream, given the target audience is somewhat low-code/non-technical.
However, having an *independent* identity provider adds a lot of value. It allows security to be managed across an organization in a consistent way, not having to build customized authn/authz for every individual SaaS that may come around.
Another thing about an independent identity is that such an identity can be used for *multiple* purposes. With a single secret, we can access more than one resource. Onestream is just one of many resources that a given service may need to connect to. It may be used for nothing more than retrieving the members of a dimension, and then using those members for some totally unrelated purposes that may have nothing to do with onestream. As such, it is bothersome to maintain PAT tokens, and deal with the consequences when someone forgets to sign into this SaaS and once a year, to do this busy-work.
