Feature request, SSO with Azure AD


As part of my going passwordless process, I wonder if it will be possible to integrate 1Password for Windows and 1PasswordX with my own Azure AD (coming with Microsoft 365 sub) for SSO? My aim is to not write master password again and again, and if possible even on initial installation 1P will take credentials from my Azure AD.

1Password Version: 7.4.767
Extension Version: 1.19.1
OS Version: Windows 10 1909
Sync Type: Not Provided


  • ag_anaag_ana

    Team Member

    Hi @Naxterra!

    Can you please clarify how you are thinking about integrating 1Password with Azure exactly? Can you give us a specific example?

    Because every time you want to use 1Password to fill your credentials on a page, 1Password must be unlocked, there is no way to fill credentials is 1Password is locked. You need to either enter the Master Password or unlock it with Touch ID.

  • Hello

    Instead of filling Master Password everytime I open my browser or opening 1Password for Windows app, it should just check if I logged with correct user to my device and then unlocks itself. For example SAP applications which are using Azure AD or normal AD credentials to login to web pages and applications, even within Microsoft Office apps. For web pages there are lots of examples, for instance antivirus pages, like Bitdefender, Symantec, Trend Micro, etc. They are using my Azure AD credentials to login web pages. Also there are lots of applications which are using Azure AD SSO which can be accessed via https://myapplications.microsoft.com/ .For browser extension there is Office extension which is using my Azure AD credentials too.

  • bundtkatebundtkate

    Team Member

    That's a tricksy one, @Naxterra. I strongly suspect this is something we could theoretically do, but probably wouldn't. I'll do my best to explain why, but if there's anything that doesn't make sense or that you don't follow, please ask questions. Ultimately, I'm probably not the best person to explain this in detail so depending on how deep a dive you want, I may need to call for help.

    With that said, this comes down to the difference between authentication and encryption, which is an interesting but often confusing distinction. Most of these services are authenticating you using your AD credentials. You're proving to the service that you are who you claim to be which doesn't necessarily require the actual password for that service. You've proven at some point that the possession of your AD credentials is a valid authenticator so if AD says you're you, that service is allowed to trust that and let you in even if you never provided the username and password specific to that service. With 1Password, you're decrypting data instead. Decrypting data doesn't require authenticating yourself at all. Instead, it requires the right key to allow 1Password to do the math and transform the data you have into something usable. So even though your AD credentials prove that you're you and you're entitled to access your data, 1Password is wholly incapable of unlocking that data without your Master Password. It doesn't know your Master Password and relies on you to provide.

    This means that the only way we could allow you to unlock with your AD credentials is by either persistently storing your encryption key in a manner that could be accessed using your AD credentials or by allowing AD to know your Master Password so that it could provide that Master Password to 1Password after authenticating you. This would definitely be convenient, but it would be terribly insecure. Imagine if your AD account were compromised. You could disconnect it from other services letting them know that your AD credentials no longer prove that you're you and those services would immediately stop allowing access to their data with those credentials. But we could not remove access to your Master Password or encryption key because we don't have either of those in the first place – they'd have to be stored locally. If the person who compromised your AD account was able to get their hands on a copy of your data encrypted with the key your AD credentials were able to access and save it along with the encryption key your AD credentials were protecting, they would have access to that specific dataset indefinitely. You'd need to change every password you stored in 1Password to protect yourself.

    You might reasonably ask why we'd store these things locally on your devices rather than storing them ourselves. After all, if they didn't exist locally, you could protect your 1Password account in the same way as others by simply cutting off access to our service. The thing is, that would leave us with access to the keys to unlock your data. Avoiding that is fairly fundamental to our security design. The idea is that we can't lose, misuse or abuse what we never have in the first place. By avoiding storage of any unencrypted data and never having your encryption key, we ensure that even if we all had our brains and bodies taken over by evil aliens bound and determined to steal our customers' data, the aliens would be incapable of doing so. We simply don't have the keys needed to allow for that. Or, more realistically, it serves to limit the types of data a rogue employee could access, and the data we could potentially compromise by screwing up (because hey, we're humans, we're probably going to screw up on occasion). We absolutely value your trust and work to cultivate it, but we don't feel you should have to trust us in order to know that your data is secure. It should be secure as a matter of course and we designed 1Password's security model on keeping that requirement to trust to an absolute minimum. After all, we could be the smartest, most well-meaning, and saintly folks on the planet but still make a mistake that exposes data or hire someone without realizing they were a bad actor. This ensures that if that happens, the only data of your they can access is fully encrypted and can only be unlocked using keys we never have. Bad actors can't steal what we don't have and we can't expose what we don't have by screwing something up so you're safe even though we're not perfect.

    I know that was a bit a novel, but hopefully it makes sense and helps you to understand why this isn't something we can reasonably do while living up to our standards of security and protection for your data. If you have any specific questions or need something clarified, though, let me know. I'll do my best to answer and if I can't, I'll find someone who can. :chuffed:

  • I understand difference between authentication and encryption, and your scenarios makes sense. But in my case nothing can get compromised. For example, my local drives are protected by Bitlocker encryption with AES 256bit XTS with TPM in place. Accounts are managed from Azure AD, not local directory. If by any chance someone get physical hold of computer, they still have to find correct passwords / PIN codes and more likely they need to access security keys plus their PIN codes (looking at my lovely Yubikeys). Even by miracle they managed to crack them, I can still lock them from cloud and wipe all data within seconds, well actually like half a minute but anyways..

    I see need for master password from your end, but on my end too many apps are supporting SSO and supporting passwordless authentication, and 1P does not.

    Azure AD can store credentials, or better to say can integrate with SAML or certificate based authentication methods, or even with user authentication, which many apps and companies support, and encouraged to do so.

    I am trying to figure out how can we make it work. How can we make a trust between 1P and AAD? Maybe add 1P and 1Px as Enterprise Application and configure SSO, so it can both authenticate and decrypt afterwards? I know master password is known and good method but it is becoming a hassle after forcing to enter it too many times. We have 2FA, emergency key and master password for initial install, and then master password for rest of it. I remember saying it before, I am closing my browsers whenever my tasks are done, and thus making me force to enter my master password to be put everytime I open browser to enable 1Px. Companion extension is good but not good as 1Px, and having issues with Edge Chromium didn't help in late times either.

  • bundtkatebundtkate

    Team Member

    The companion extension would probably be my one best suggestion for that particular struggle, @Naxterra, and you're getting a bit deeper into the weeds than I'm probably qualified to tread on the AAD trust so I don't know that I can do you much better on my own. The companion extension should work fine with Chromium Edge (though you do need to enable "extensions from other stores" since we point to our Chrome extension rather than separately hosting on the Edge Store), but I know there are folks who far and away prefer 1Password X so that still leaves the concern of which is most usable for you.

    Ultimately, I think the genuine solution to this will be (eventual) integration between 1Password X and the desktop app, but I don't want to ignore your comments on AAD so I've asked one of our security team to pop in and discuss that in more depth. It is a Canadian holiday today (beyond being a bit late for us North Americans anyway), so you might not hear from them until tomorrow, but I'll be sure to give them a poke when I'm in tomorrow if they don't hop in earlier. :chuffed:

  • LarsLars Junior Member

    Team Member

    @Naxterra - sorry it's taken so long to respond to you here. It's been partly because I don't have a lot to add to bundtkate's already excellent replies. Over the years, we've considered various ways to accelerate or ease the use of 1Password including integration with other services, but this is a bridge we're just not willing to cross, as things stand now. In order to accomplish what you're asking for, we would need to give Azure access to your Master Password and Secret Key -- these are how your data is decrypted, and try as we might (and have!) there isn't any way around that, which means we're just not going to be doing it, at least the way things stand currently.

    I'm sorry if that's not the answer you were hoping to hear, but that remains - for now - the one we're sticking with: we will not put ourselves in a position where we are able to know your Master Password or Secret Key, let alone share them with other authentication-based mechanisms. If a way to do that securely in the future arises, we'll certainly look into it. But for now, no.

  • Okay, thank you.

  • bundtkatebundtkate

    Team Member

    It's no trouble at all, @Naxterra, and I'm sorry we don't have better news for you. Hopefully, we'll see some movement forward on desktop app integration for 1Password X on Windows in the near future so you can at least rely on Windows Hello to better limit having to type your Master Password. I know that's only addressing one request among many, but it sounds like the biggie so I've got my fingers crossed it gets things most of the way towards your perfect solution. :+1:

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file