none
App registration does not have "Keys" option available RRS feed

  • Question

  • I've created a App Registration in Azure AD however, the "Keys" option in the Settings blade is not displayed.  Based on all the articles I've read, this option should be available but for some reason it is not.  How do I make this option available?

    

    Tuesday, October 17, 2017 10:59 PM

Answers

  • Hi Andrew/ All, 

    I have found the reason for the Keys option no longer being available. 

    It turns out there was bug in the Portal a few months back that enabled the use of Key Secrets for Native apps. This was never intended as Native apps are public clients so they should not have Keys/ Credentials. So there was never an intention for customers to use keys on native apps in the first place. 

    This bug was recently fixed on 9/20 hence the reason you are no longer seeing that keys option in the portal. 

    If this feature is something you need as your app is not designed to be public then the only mitigation there is at this point would be to recreate the app and select the Application Type Web APP/ API. This will allow you to use the keys functionality. 

    I understand this solution is not ideal however since the purpose of Native apps are to be public there is no plan to add this feature back into the mix. I apologize you were impacted by this bug. I am bringing the point that we need to make our documentation more clear regarding the types of applications and what features they offer. Again, I apologize for the inconvenience this bug has caused.

    -Micah  

    Tuesday, October 24, 2017 6:29 PM
    Moderator
  • Hi Adam, 

    I did some testing and it looks like the Key tab is not available to you because of the application type you selected. You picked Native. 

    If you pick Web App/ API during creation you will see the Keys tab. 


    Tuesday, October 17, 2017 11:31 PM
    Moderator

All replies

  • Hi Adam, 

    I did some testing and it looks like the Key tab is not available to you because of the application type you selected. You picked Native. 

    If you pick Web App/ API during creation you will see the Keys tab. 


    Tuesday, October 17, 2017 11:31 PM
    Moderator
  • Thanks Micah. That worked.  
    Tuesday, October 17, 2017 11:38 PM
  • Great! Happy to hear it :) 
    Tuesday, October 17, 2017 11:39 PM
    Moderator
  • Is this something that recently changed?

    I actually have a Native app with keys I have created for it that are still working. I am now unable to create new keys, however.

    Thursday, October 19, 2017 2:20 PM
  • Thanks Micah.  That worked.  It's strange because I'm 90% sure that the keys option used to be available for a native app.  
    Thursday, October 19, 2017 3:52 PM
  • I actually have keys created for a "native" app, which I can use, but I can't revoke or manage! It appears to be an unannounced breaking change. Thanks, Microsoft!

    For our purposes, we have an automated bash script that accesses resources in Azure (which authenticates via client credentials grant). I gather the rationale for removing the option is that a mobile app shouldn't be trusted with secrets, but I don't think our approach is unreasonable.

    If Microsoft's recommendation for that scenario is to call that a "web" app, OK, but that's not a configurable option for an existing application.

    What is Microsoft's guidance for existing authorization scenarios that are now broken?

    Thursday, October 19, 2017 4:19 PM
  • Hi Andrew, 

    I did some digging and it looks like some of the documentation was updated on 10/4.

    Taking a look at the doc located here I see the following in regards to creating a new app:

    Application type:

    Not sure if that fully relates to your environment or not. I am assuming this change was recent though I have not yet been able to trace the exact date yet. 

    Do you get any errors when you try to manage the keys on your native app? A screenshot might prove useful. 

    -Micah


    Thursday, October 19, 2017 5:01 PM
    Moderator
  • Hi Andrew, 

    I believe you are correct. Seems a couple other people have native apps where the keys functionality was still there. I am not yet sure of the date of the change. 

    I mentioned to Andrew below that I found some documentation located here that was updated on 10/4. It specifies when to select Native and when to select web app/ API.

    Do you have any native apps that still have the keys portion available? 

    Thursday, October 19, 2017 5:04 PM
    Moderator
  • Micah,

    Thanks for your research.

    The problem isn't that I receive errors. The problem is I cannot manage keys on my app at all! The option is no longer available, as your earlier screenshots show. I can still authenticate and receive a token from my AD tenant's token endpoint using credentials I set up previously. I can no longer manage these credentials, though, which is ludicrous.

    My use case doesn't fit the given definition of a "Native" app or a "Web" app. I made the judgment that it was closer to a native app, but for the sake of argument, let's just say I made a mistake in my initial configuration. What is the official guidance for those of us caught by this change?

    Also, please inform me what else is going to change. Will these credentials that I can use but can't manage be revoked at some point? It's a bad situation either way. If so, that breaks running applications. If not, you have opened up a security risk by taking away the ability to rollover to new secrets.

    Thursday, October 19, 2017 5:53 PM
  • Thanks for all those details Andrew. 

    I am currently working on getting some information about this subject from the engineering team that manages it. 

    I will come back and update this thread once I hear back. 

    -Micah

    Thursday, October 19, 2017 7:12 PM
    Moderator
  • + more information while I am waiting to hear back on the original ask. 

    using the Powershell azure ad preview module:

    $app=New-AzureADApplication -PublicClient $true 
    New-AzureADApplicationPasswordCredential -ObjectId $app.ObjectId

    This should set effectively an app secret to a native app. So you could try to renew your secrets and add/replace password credentials (aka keys) via PowerShell. 

    I will still come back with more information when I have it available. 

    -Micah


    Thursday, October 19, 2017 7:34 PM
    Moderator
  • I'm hesitant to try this without some experiments first, but this does appear to be what I want.

    For others browsing this thread, I was able to find the documentation here (can't post actual links, it appears.):

    docs dot Microsoft dot com/en-us/powershell/module/azuread/new-azureadapplicationpasswordcredential?view=azureadps-2.0

    docs dot microsoft dot com/en-us/powershell/module/azuread/remove-azureadapplicationpasswordcredential?view=azureadps-2.0

    Can you confirm the explanation for removing the feature? And, if there is an alternative in PowerShell, why is it OK to have the feature in PowerShell, and remove it from the portal? Is it also scheduled for removal from PowerShell? (Unless I'm mistaken, I don't believe it was ever in the "az" command line tool, which is actually my first preference.)

    Thanks again for your efforts. I would certainly appreciate more transparency on the issue.

    Thursday, October 19, 2017 8:56 PM
  • Yes, Agreed some testing should be done before implementing fully for sure :) 

    I will review the links you provide and try to get some clarity on the questions you have directly from the engineers that create these features. Will update you once I have more. 

    -Micah

    Thursday, October 19, 2017 9:03 PM
    Moderator
  • Micah,

    What are your updates?

    Monday, October 23, 2017 12:41 PM
  • Hi Andrew, 

    No work back from anyone who manages the app. I did hear back from some others that work a lot with these kind of apps

    They had the following to say:

    "This makes sense to me. Native AD Apps are only used with Delegate Permissions, meaning the involvement of a user during the sign-in process. Moreover, these native apps consumers do not share a common space (unlike a webapp), so each device, each app is used by indivudual users.

    App secrets are usually used with App-only permissions where you use the ClientCredential code grant from backend jobs or from backend APIs. Web Clients (ASP.NET MVC for instance) use both delegate/app-only permissions and indeed also use an app secret even when it comes to accessing resources on behalf of the logged-in user but the web context is shared across multiple users at the same time, so I guess the utilization of this secret is to have a stronger authorization process. 

    Suggested Mitigation: Azure ad webapi kind of apps can also be used from native consumers but you need to make sure you have an appropriate location to safely store the secret. So essentially it is recomended that if you need to use Key secrets the best bet might be to migrate from a native app to a web app/ API based."

    Looking further into the Integrating Applications with Azure Active Directory

    It mentions to select "Native" for client applications that are installed locally on a device. This setting is used for OAuth public native clients. And select "Web app / API" for client applications and resource/API applications that are installed on a secure server. This setting is used for OAuth confidential web clients and public user-agent-based clients. The same application can also expose both a client and resource/API.

    That being said, I am reaching out to the doc owner to see if they have any idea when/ why this feature was removed via the portal. You can also follow this post here.

    Aplogies for the delay however it appears finding the exact information you are looking for has proved more difficult than expected. 

    -Micah

    Monday, October 23, 2017 5:14 PM
    Moderator
  • Hi Andrew/ All, 

    I have found the reason for the Keys option no longer being available. 

    It turns out there was bug in the Portal a few months back that enabled the use of Key Secrets for Native apps. This was never intended as Native apps are public clients so they should not have Keys/ Credentials. So there was never an intention for customers to use keys on native apps in the first place. 

    This bug was recently fixed on 9/20 hence the reason you are no longer seeing that keys option in the portal. 

    If this feature is something you need as your app is not designed to be public then the only mitigation there is at this point would be to recreate the app and select the Application Type Web APP/ API. This will allow you to use the keys functionality. 

    I understand this solution is not ideal however since the purpose of Native apps are to be public there is no plan to add this feature back into the mix. I apologize you were impacted by this bug. I am bringing the point that we need to make our documentation more clear regarding the types of applications and what features they offer. Again, I apologize for the inconvenience this bug has caused.

    -Micah  

    Tuesday, October 24, 2017 6:29 PM
    Moderator
  • Thanks for the update. The reasoning is what I anticipated, and the steps we are already taking are in line with your suggestion.

    We have production software relying on the so-called bug, however. The question you didn't answer is whether any further steps are being taken regarding native app registrations that were created with secrets, particularly whether secrets would be removed or become unusable at some point. Can we have a guarantee that nothing is being modified on the app registration itself, at least for some period of time while we roll over to using new app registrations?

    Secondarily, can you speak to whether the PowerShell functionality is being removed as well?

    Regarding any rework to your wording and documentation, we have various Linux devices running scripts that communicate with Azure resources. The scripts are acting as clients, not servers. The scripts are running "locally", although they are not "public" in the respect that they are never deployed on untrusted devices. Our use case does not cleanly match the definition of web or native app, although it aligns more closely with native app. Since native apps used to allow keys, that made the most sense for us. Documentation, tool tips in the portal, etc., etc. should, I believe, simply make a distinction between "public" and "non-public" apps, rather than whether the app is "installed locally on a device" or "installed on a secure server" (which, though generally correlated to public and non-public, is actually not the relevant consideration).

    Tuesday, October 24, 2017 10:01 PM
  • Hi Andrew, 

    The group that confirmed the bug in the portal did not mention anything regarding the PowerShell options being removed. Those options were not enabled by accident so I do not see them going away at least not any time soon. In fact, the way we found to enable a secret on a native app would just be considered a work around if anyone did want keys on their native apps.  

    There are no plans to further modify any native apps that were created and are using keys. That being said, I cannot guarantee that nothing will change while you work on rolling over your app. What I can say is that we do not ever intentionally add or remove any features that impact customers productions environments. In this case it was just unfortunate we were unable to find and fix the bug prior to you going to production. 

    Again, apologizes for the inconvenience this whole incident caused you. 

    If you have any additional questions please just let me know. 

    -Micah

    Thursday, October 26, 2017 12:03 AM
    Moderator
  • I changed Application type to Web App/API and I started seeing Keys option. But it does not display any Key value under it even after saving the App Registration. How do I get Key? 
    Saturday, October 6, 2018 11:05 AM