How can I migrate oauth users to a different oauth provider?

Grafana Authentication
, ,
21

I would do some sql script to update things in the backend but is it worth it and are you comfortable with that? or use the UI to reset permissions. or use api to do it. either way it will be messy. pick your poison

22

I guess it depends how complicated you expect this sql script would be. We have a separate test setup from our production setup and we have a script to pgdump from the production db to the test db, so I can easily iterate on the process. The main issue I see that I mentioned above is that I don’t know how to generate new user_auth config for every user without instructing every user to log in once. Maybe there is a different approach than what I thought of that would work better.

23

maybe you dont have to if you just update via script from

auth_module = oauth_generic_oauth to auth_module = oauth_okta

restart grafana. I would try that first. do it for you and a small set of migration test users and see what happens.

24

Well, in the case of the old and new user_auth rows generated by my own user, the auth_id field is the same but the following fields are all different:

  • o_auth_access_token
  • o_auth_refresh_token
  • o_auth_token_type
  • o_auth_id_token

do you think it will still work if those fields are not also modified in addition to the auth_module field?

I tried restoring our test db and then running this query UPDATE public.user_auth SET auth_module = 'oauth_okta' WHERE user_id = 2; where 2 is my user ID. There are about 100 entries just for my user_id in the user_auth table. I then restarted grafana with kubectl rollout restart. After doing this I still get the same error message trying to log in.

25

so maybe you also need to update all net new column values that changed. uncharted waters hacking here as there is no official docu. again I would submit a feature or even a bug fix request? if you migrate to something the other data pieces should align. it should not create a new user with view perms and with the new user you have lost to all other permission to dashboards etc

26

Using the skip_org_role_sync option on the oauth provider (so with the okta provider via env vars it’d be GF_AUTH_OKTA_SKIP_ORG_ROLE_SYNC: "true") solves the issue of user role being set to Viewer upon first login, which is great. I am able to switch from the generic oauth provider to the okta provider seamlessly. The only remaining issue is that I need to have GF_AUTH_OAUTH_ALLOW_INSECURE_EMAIL_LOOKUP: "true" set until every user has logged in once or else I’ll get the user already exists error.

1 Like
27

but what happens after everyone logs in and then you reset GF_AUTH_OAUTH_ALLOW_INSECURE_EMAIL_LOOKUP to false? You need to test everything in pre prod so as not to get any surprises would be my feedback