AAD Apps versus Yammer Apps to consume Yammer APIs


A while ago, I wrote a series of blog posts on how to develop Yammer Apps and what you could expect from the Yammer App model in scenarios where you’d leverage Yammer from SharePoint. Since then, Microsoft has added the possibility to consume Yammer REST APIs from Azure Active Directory Apps.
When you create an AAD App, you can add Yammer in the list of permissions of the AAD App as shown in the below picture. When doing that, it means that your AAD App can be used to get an Access Token for the Yammer Resource (https://www.yammer.com/) in order to consume the Yammer endpoints such has “https://www.yammer.com/api/v1/users/current.json” or “https://api.yammer.com/api/v1/users/current.json”.

So, what’s the difference between both and when to use which? Here is a non exhaustive list of major differences:

  • Yammer Apps can be deployed to Yammer’s App Directory which is not possible with AAD Apps
  • Yammer Apps (Enterprise) can get a token for any user in the enterprise and thus, pretend to be that user and interact with Yammer on his behalf. To achieve this, you don’t even need to get the user sign in nor his consent. That cannot be done with AAD Apps where you must get the user signed in at least one to obtain a token and act on his behalf. Moreover, for the time being, there is no App Only permissions available for the Yammer service in AAD. Read my other blog posts if you’re interested to know how to use the Global Admin Tokens and impersonate any user.
  • Yammer’s Apps Access Token *never* (Yammer says it might expire…) expires where AAD App’s Access Tokens live for 1 hour. You can get fresh Access Tokens thanks to a Refresh Token but that guy also has an expiry date. Once the Refresh Token has expired, you must involve the user to sign-in again to get a new Access Token and a new Refresh Token.
  • For the time being, with Yammer Apps and Global Admin Tokens, you can target any REST API, in short, you’re king with such a token. With AAD Apps, you can “read” and “write” to Yammer. I’ve not tested every single endpoint but I guess that you’ll be able to do what you can usually do with the UI.

So, now that the major differences were listed, when should you privilege one over the other?

Use AAD Apps if:

  • You plan to use Azure in general as a backend/front-end environment
  • You plan to use the same AAD Apps to target other SaaS such as SharePoint Online etc..
  • You don’t need to consume the Yammer API as an App Only, as it is not (yet…) available.

Use Yammer Apps if:

  • You want to enrich the Yammer Directory with extra features
  • You need to perform actions on behalf of users without their consent. In the context of an Enterprise, there are tons of such scenarios so although this can be questionable from a security perspective, it makes a lot of sense from a functional perspective

Happy Coding!

About Stephane Eyskens

Office 365, Azure PaaS and SharePoint platform expert
This entry was posted in Azure Active Directory, Office 365, Yammer and tagged , , , . Bookmark the permalink.

1 Response to AAD Apps versus Yammer Apps to consume Yammer APIs

  1. Geno Salvati says:

    Can you please detail the steps needed to get Yammer working through AAD? I have configured API permissions in AAD and am submitting my request to the yammer rest api using my token. Result is 401.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s