I haven't encountered IsLocked
and MayEdit
as system fields on Contact (or Account) previously.
Are you using the Approval feature in that Org?
From my searching it seems like the problem fields are specifically related to that particular feature.
If that is the case, you may need to explicitly ignore those system fields. It may also indicate a problem with the Apex describe calls.
Your assessments are pretty close, but you've got some glaring errors I'd like to bring up.
Custom Settings / No Encryption?
You can encrypt the token using the Crypto class if you need to. Just because it doesn't support the Text (Encrypted) data type doesn't mean it's impossible.
Custom Metadata Type / Requires Query
In addition to the same comment about Custom Settings, Custom Metadata does require a query, but these queries do not count against governor limits at all (SOQL row/query limits do not increment). The major con that you missed, though, is that you cannot update a Custom Metadata entry via Apex Code directly, but instead have to leverage a metadata API call instead. This makes it non-trivial to implement in Apex Code/Visualforce/Lightning because of the extra hoops for simply storing a token.
No Auth. Provider
In Lightning Experience, it's under Identity > Auth. Providers, and in Salesforce Classic, it's under Security > Auth. Providers. In either case, you need the Manage Auth. Providers permission. Check your profile settings if you're on a custom profile, or create a permission set for yourself.
Questions
Can Named Credentials be used to support token based authentication?
Yes, that's one of the primary benefits of using Named Credentials.
Is it necessary to set up My Domain in order to do so?
No, I just set up a Facebook OAuth2 connection in a dev org without My Domain configured, so it's clearly not necessary.
Is there really any worry about standard users seeing the token values?
Technically, you should treat the token the same as a password. That said, most users in your system wouldn't know what to do with a token if you told them how to use it, the few that do are probably developers that need to be trusted with these tokens anyways, and anyone that intends harm shouldn't even be an employee, much less someone that can log in with enough permission to see the token.
Is there any benefit to encrypting the token?
In a typical org, there's little need to encrypt the token. As a bonus, Named Credentials seems to store the token in a place that can't be accessed even by admins (not that I could see anywhere), so using NC limits interactions to just programmed interactions and, for developers and admins, execute anonymous scripts. I would personally recommend NC as the preferred form of authentication.
Closing Notes
Named Credentials are purpose-built for OAuth authentication, and should be the preferred means of doing so over all other means. The other techniques exist primarily because they were invented by thousands of developers independently, which salesforce.com obviously noticed, and decided to provide a standardized interface for us to use.
Identity Provider configuration allows salesforce.com to act as an Identity Provider, which means you could log in to services like Twitter, Facebook, or your internal apps using your salesforce.com user login. It's not used for outbound authentication at all.
Best Answer
A token is a "placeholder" of the object or field it points to. It consumes very little resources, as compared to a describe, because it doesn't actually contain any information about the field or object, such as its label, data type, maximum length, etc. A describe can contain hundreds or even thousands of bytes of data, but a token is significantly smaller (less than 20 bytes).
To consider the savings, if you have 500 custom fields, 500 tokens might be 10,000 bytes of memory, while a full describe for all 500 fields would probably use closer to 500,000 bytes of memory.
As a bonus, you can also use tokens in place of strings when using the generic SObject methods
get
andset
, which reduces the possibility of the system throwing an exception because of a typo; the fields are statically checked at compile-time.As an example of the prior paragraph, consider this code:
The first error might be harder to track down because it won't show up until you're testing, while the second one will surface immediately because of the compile-time checking.
Schema.DescribeSObjects()
is a function that returns full object-level details for one or more SObjects, such as the type of name field (text or auto-number), its singular and plural labels, and accessibility information. You can use this information to render strings dynamically, provide branch logic depending on the accessibility of the object for the current user, and more.The return value (the result) of the function is one or more
DescribeSObjectResult
objects that actually contains the describe information fromDescribeSObjects
orSobject.getDescribe()
.There are two types of describes:
DescribeSobjectResult
andDescribeFieldResult
. As they are named; the former contains data related to an entire SObject, such as its label and child relationships, while the latter contains information such as the formula used for default values, or picklist values).