🎉 Exciting News: OAuth 2.0 is Now Available! 🎉

[Oren]

Hello Meraki Community!

We are thrilled to announce that OAuth 2.0 is now available for all Meraki API users! This marks a significant milestone in enhancing security, flexibility, and control for your integrations with Meraki.

Why OAuth 2.0?

• Enhanced Security: OAuth 2.0 replaces static API keys with short-lived access tokens, reducing the risk of unauthorized access and ensuring your integrations are secure.
• Granular Access Control: Define precise scopes for your applications, granting only the permissions they need - nothing more, nothing less.
• Seamless Token Management: Enjoy automatic token expiration and the ability to refresh tokens effortlessly, keeping your integrations running smoothly without manual intervention.
• Improved Traceability: Each API request is tied to a specific application, simplifying auditing and helping you maintain accountability and compliance.

Get Started Today!

We encourage all developers and integration partners to explore our updated OAuth 2.0 documentation and start integrating these powerful features into your applications. We’ll even throw in a sample Python script to help you get started.

Whether you’re enhancing existing integrations or developing new ones, OAuth 2.0 provides the robust foundation you need.

When is OAuth an overkill?

“With great power comes great responsibility” or, in the case of OAuth, a bit of overhead.

Our current OAuth 2.0 implementation is designed for backend to backend integrations, where your backend can manage and refresh OAuth tokens when needed as well as provide an accessible redirection URL.

If you’re looking to run a small ad-hoc script - it might be an overkill.

Thank you for being part of the community, happy coding, and keep the feedback coming!

Best,
Oren.

[GonzagueD]

Hello @Oren first of: thanks, this is super cool to now have OAuth, much more fluid for end users than API keys (even if as your post reminds, a bit over overhead ^^) 

Could you guys make the integration portal a little more rich? For example for the moment, it is missing the possibility to add a logo, the name of an editing company and .. I can even name my app "Meraki" :

Also it would be nice to be able to submit our apps from this portal to the Meraki marketplace! (ok the nw renamed Cisco Networking App Marketplace)

Otherwise, so far so good

Thanks

[Oren]

I’m glad to hear. Thanks for the feedback.

This is our first release and we will be adding more features. 

If/when the marketplace listing submission will be done from integrate.cisco.com, we would allow ecosystem partners to upload a logo, company details, and rich media there. Currently, you won’t see a logo anywhere and it adds no value to ask you for one. 

I hope this helps. Keep the feedback coming!

[GonzagueD]

Good point , at least then the "Developed By", "Category" and "Website" that are displayed in the integrations ? 

[Oren]

Good question. We'll be adding these for ecosystem partners, until they are self-served.

[imuccini]

We are receiving sometimes an error message when refreshing the token:
"The maximum number of active access tokens has been reached"

Maybe it is something happening only during testing phase where we may hit the refresh frequently during debug and testing.

Our application makes frequent use of some APIs, so we are renewing the token every hour. Are there specific recommendation to achieve this use case without hitting the max number of tokens?

[Oren]

Hi @imuccini,

How many instances of the applications are running in parallel? What is the OAuth client ID? 

[imuccini]

A few actually, but less than 10. Is there a limit also on the number of customers that can use our oAuth App to connect our product with their Org?

I'll share with you the Client ID in a private message.

[RCocks]

Hi @Oren ,

I am trying to follow this flow, but it is unclear from the documentation which scopes apply to which API endpoints.

For example, which scope covers getOrganizationDevices ( /organizations/{organizationId}/devices ) and which scope covers  getOrganizationNetworks ( /organizations/{organizationId}/networks ) please?

It would be useful if this data could be included on the API documentation page, so we could easily go from URL to scope.

Kind regards,

Richard

[Spaz]

We use many more endpoint, would also like to know the answer.

[Oren]

I’m glad to hear you’re looking at implementing OAuth.

We are working with the DevNet team on having the scopes on each operation’s page. Meanwhile, you can use the API index page to see all operation-to-scope assignments. 

[RCocks]

Thank you, that's exactly what I was after.

[rcocks-hl]

Hi ,

Thank you for your help so far. I've now had the opportunity to use this further and have some questions regarding implementation.

The `refresh_token`, while designed as a "long lived token", invalidates itself when used to generate an access token.  The response includes a new refresh token along with the access token.

That behaviour is an optional part of the OAUTH2 spec, and it is one that causes a problem for working with distributed agents, because the refresh token has to be coordinated across any machines that need to generate access tokens.

It would be helpful if there were the ability to only regenerate the refresh_token on a long-lived basis, and not every time an access token is generated.

This would allow each agent to use the (securely stored) refresh token without needing cross-machine coordination, except that which naturally happens over a much longer timescale.

Are there any plans to support any other grant types for more easier trusted machine<->machine communication, such as client credentials grant?

Kind regards,

Richard

[Oren]

Hi Richard,

Thanks for sharing your experience.

The refresh token is long-lived in the sense that as long as it's used at least once every 90 days - it can last forever. Token rotation is described here, and the purpose of rotating both refresh token and access token is to prevent replay attacks.

I'd like to better understand the scenario, so we can make sure we have a good way to address it.

For a distributed system, have you explored central vaults like AWS secrets manager, Hashicorp Vault, etc'?