Outlook Add-In 3rd party authorization

Get Help
,
1

I develop Outlook add-in that should be able to send data to my server. To do this I added authorization flow using Auth0 (same as I do in frontend app)

I am not sure if this approach will pass add-in review for publishing on the marketplace

  1. Is it ok to store access-token in localstorage? If not, what approach to use?
  2. Where to store subscription key I use for Auth0?

I would be grateful for any code examples or links to documentation that demonstrate a secure, third-party authentication flow (specifically with Auth0) for an Office Add-in that would be compliant with AppSource policies.

3

Hi @JohnDoe1AUTH,

Welcome to the Auth0 Community!

It’s great to see that you’re thinking about AppSource compliance from the start, as security is a critical aspect of the review process for Outlook Add-ins. Let’s break down your questions about third-party authorization with Auth0.

  1. Is it ok to store access-token in localstorage? If not, what approach to use?

Access tokens are generally not supposed to be stored in localStorage in a production environment, especially for Office Add-ins.

The most secure and recommended approach for handling tokens in an Office Add-in, especially when interacting with a third-party service like Auth0 and your own server, involves a backend component and secure OAuth 2.0 flows.

Authorization Code Flow with PKCE (Proof Key for Code Exchange): This is the recommended OAuth 2.0 flow for public clients (like your Add-in’s frontend) where a client secret cannot be securely stored.

Microsoft’s Single Sign-On (SSO) for Office Add-ins: If your primary authentication is with Azure AD (Microsoft 365 accounts), you should strongly consider leveraging Office Add-in’s built-in SSO capabilities.

Use both in conjunction for maximum security.

  1. Where to store subscription key I use for Auth0?

By “subscription key” do you mean the Auth0 Client Secret or any other similar sensitive API key? If so there are two places you can store your Client Secret.

Your Backend Server’s Environment Variables: This is the standard and most secure practice. Store the Auth0 Client Secret as an environment variable on your backend server. Your backend code can then access this variable when making server-to-server calls to Auth0 (e.g., during the authorization code exchange or token refresh).

Azure Key Vault or Similar Secret Management Service: For more robust and scalable solutions, especially in cloud environments, use a dedicated secret management service like Azure Key Vault, AWS Secrets Manager, or Google Cloud Secret Manager. Your backend server would then retrieve the key from this service at runtime.

If you have any other questions, feel free to reach out.

Have a good one,
Vlad