I've been over this concept with customers and support engineers so many times, that I'm not sure why I haven't posted about it before.
My colleague Adam posted on this topic a while back, but I wanted to expand on that a bit.
Let's say you have a SharePoint (2010, 2013, 2016, 2019, -- doesn't matter) web application using Windows-Claims authentication: http://share.contoso.com
You've been using this for years, assigning permissions all over the sites.
You then decide to make the site available externally, so you configure Active Directory Federation Services (aka: ADFS or AD FS) and configure the http://share.contoso.com web application to use that authentication type as well.
You browse to the site and log in via ADFS and you're greeted with the Access Denied page:
"Sorry, this site hasn't been shared with you"
You then log out and log into the same site using your Windows Credentials, and you get the access you expect.
A Common Misconception:
As far as SharePoint is concerned, your Windows auth account and your ADFS auth account are completely separate users.
As such, your ADFS account must be permissioned separately. It has none of the access that your Windows auth account has, and there is no way to "link" the two.
I don't blame you for expecting the ADFS account to have the same permissions as the Windows account. After all, they both come from the same user object in Active Directory. However, SharePoint doesn't actually know that you're using Active Directory or ADFS. All SharePoint knows is that you're using "Trusted Provider" authentication and it received a SAML token that was signed by a trusted certificate. That SAML token could be from ADFS with an Active Directory back-end, or it could be from Ping Federate with a SUN LDAP back-end, or anything in between.
If you look at the account names used in each case, it should become clear:
As you can see, the account names are different. As far as SharePoint is concerned, they're as different as "Bob" and "Jeff", and will never "share" permissions.
What to do?
There's a few options:
1. Re-permission all of your accounts separately so that the ADFS version of the user has the same access as the Windows version.
Note: This is by far the worst option, especially if you plan to allow users to continue using both auth methods. There's nothing to "link" the accounts or keep their permissions in sync. Not to mention, 'person or group' list columns (like "Modified By") will show different user accounts depending on how the user authenticated. This is pretty much unmanageable. I only mention it first to get it out of the way.
2. Use one authentication method or the other, not both. You would want to migrate all of your Windows accounts to their respective ADFS accounts within SharePoint. There are a few different ways to do this including the Convert-SPWebApplication command, and Move-SPuser. See this post from my colleague Adam, where he walks through it: https://blogs.technet.microsoft.com/adamsorenson/2018/01/17/sharepoint-20132016-migrate-from-windows-claims-to-adfs/
3. Use Web Application Proxy (WAP) to separate the ADFS authentication piece from SharePoint. The idea here is that you use ADFS to authenticate to WAP, which then translates you into a Window auth token, and passes that on to SharePoint. This is kind of "the best of both worlds". You can use it to enable external access to SharePoint and authenticate via ADFS, yet you don't have to migrate any of your users within SharePoint because it's still using Windows auth by the time you get to SharePoint. References: