How can I separate SSO and offline access OAuth flows with OmniAuth and Devise in Rails 8?

Below is a summary of a few approaches you might consider:

1. Separate your middleware stacks and namespaces
   Devise’s omniauthable module will hook into OmniAuth’s middleware and override certain routes (e.g. the request phase) for all providers you configure there. One approach is to “isolate” your standalone OAuth flow in its own namespace or even a separate middleware stack. For example, you might mount a dedicated Rack app (or at least a separate endpoint) that initializes its own OmniAuth::Builder, separate from what Devise uses. This way the non–Devise strategy won’t be colliding with Devise’s routes.

2. Use different provider names or custom strategies
   If you can use a different provider name for your second Microsoft flow (for example, using a custom strategy whose name isn’t used by Devise’s SSO), then you can avoid conflicts in route dispatching. In your initializer you might have something like:

   RUBYCopied
   Rails.application.config.middleware.use OmniAuth::Builder do
     provider :microsoft_v2_auth, ENV["SSO_MICROSOFT_APP_ID"], ENV["SSO_MICROSOFT_APP_SECRET"],
       scope: "openid profile email"
     
     # Use a custom provider name for the offline access flow 
     provider :microsoft_offline, ENV["GRAPH_MICROSOFT_APP_ID"], ENV["GRAPH_MICROSOFT_APP_SECRET"],
       scope: "offline_access User.Read", setup: true
   end

   Then, ensure that only the desired endpoints are handled by Devise (which will likely use the default provider names it is set up for). The custom one you created won’t be “captured” by Devise’s omniauthable mapping if you don’t list it in your User model.

3. Manually initiate the request phase when needed
   As a workaround, you can bypass Devise’s automatic routing for a given provider by initiating the request phase manually. This may involve adding your own controller action that triggers the request phase on your standalone OmniAuth strategy (by directly calling the strategy’s request_phase). Routes dedicated to this flow can then live outside Devise’s scope. This approach is a bit more involved but gives you full control of when and how the non–Devise OAuth flow is started.

4. Evaluate consolidating or rethinking authentication boundaries
   If it’s acceptable within your app’s architecture, another alternative is to merge both flows into the same OmniAuth configuration but control scopes dynamically (perhaps via additional parameters or a custom setup phase). This can be tricky, especially if you need to separate the permissions requested for SSO from those needed for offline access. However, if you can detect which flow is beginning in a custom setup callback, you might be able to “split” the behavior without needing to disable Devise in one place.

In summary, the collision you’re experiencing is due to Devise’s integration with OmniAuth, which assumes a single, unified use of a given provider. To avoid that collision, you’ll need to either separate the middleware usage (by mounting a separate stack or namespacing your routes), differentiate the providers (using different names or custom strategies), or manually control how the request phase is initiated for your secondary authorization flow.

Each approach carries its own trade-offs, so your choice will depend on how comfortable you are with customizing OmniAuth and how isolated you need the two flows to be.