I'm fairly (haven't looked that much into v1) certain the user that is matched from the Auhorization HTTP header Bearer token validation is set as the thread's current principal.

So I think you're correct and it's only security roles and visitor groups that can work by Identity.Name that will function.

In v2 you can just use cookie security and do CD API calls from client side which of would expose client's IP/User Agent/Cookies/Session etc into the content fetching which I assume will get any personalization to work as normal (maybe with the exception of tracking).

If you want to personalise you would probably need to explicitly specify data to enable visitor groups to be evaluated and then personalise for as part of the request to the API. The API doesn't seem to have a facility to pass information to assist with this, and as the API is RESTful (and thus stateless) there wouldn't be any other way of doing it.

Worth pointing out that as the ContentAPI is run on the same domain and in the same server context as the regular site any requests to it from a browser, including JS, should include the same cookies as when browsing the site normally. 

The API would of course have the same VG session limitation as the rest of the site has. 

Of course you can still use the Visitor Groups that are time based like time of day.

Whether the API is actually doing though, is not something I have an answer to yet.

When I get more information I'll update here

 Hi all

For Search package, you can pass param Personalize. 

The CMS package, we understand our current short comming. But it's quite risky if we add this param to our endpoint without discussing carefully. So for the version 2.x.x, it will not be supported by default for endpoint. However, good thing is that we expose API loosely enough for your customization. You can manipulate with personalisation by customizing our DefaultContentModelMapper. 

1. Create a new class - CustomContentModelMapper inherting DefaultContentModelMapper. Registering it with ServiceConfiguration and in DependencyResolverInitialization (alloysite)

public void ConfigureContainer(ServiceConfigurationContext context)
{
//Implementations for custom interfaces can be registered here.

context.ConfigurationComplete += (o, e) =>
{
//Register custom implementations that should be used in favour of the default implementations
context.Services.AddTransient<IContentRenderer, ErrorHandlingContentRenderer>()
.AddTransient<ContentAreaRenderer, AlloyContentAreaRenderer>()
.AddTransient<IContentModelMapper, CustomContentModelMapper>();
};
}

2. With CustomContentModelMapper:

[ServiceConfiguration(typeof(IContentModelMapper), Lifecycle = ServiceInstanceScope.Singleton)]
public class CustomContentModelMapper : DefaultContentModelMapper
{
public CustomContentModelMapper(IContentTypeRepository contentTypeRepository, ReflectionService reflectionService, IContentModelReferenceConverter contentModelService, IUrlResolver urlResolver, IEnumerable<IPropertyModelConverter> propertyModelConverters) : base(contentTypeRepository, reflectionService, contentModelService, urlResolver, propertyModelConverters)
{
}

public override ContentApiModel TransformContent(IContent content, bool excludePersonalizedContent = false, string expand = "")
{
var personalization = System.Web.HttpContext.Current.Request.Params["personalization"];
return base.TransformContent(content, string.IsNullOrWhiteSpace(personalization) ? excludePersonalizedContent : Boolean.Parse(personalization), expand);
}
}

In this way, you can take advantage of personalization param in your request. Let me know your further issues

I will be doing the Content Delivery API calls server-side (server-to-server). So, if we look at it as a four-step model:

1. Browser
2. Generic .NET Website
3. Content Delivery API
4. Episerver CMS

This means that there is no direct connection between the user's browser (#1) and Episerver (#4) -- the user's browser will be talking to a generic .NET website (#3; a WebAPI site, actually, in Azure). All requests to the Content Delivery API will be server-side, from that WebAPI site.

So, this means that the only personalization information that will go through that Content Delivery API request is the information that I put in there. I could conceivably read stuff from the browser (#1) from the WebAPI site (#2), then "proxy" that into a Content Delivery API request (#3), but that seems like a lot. In doing that, I would basically be impersonating a browser from a server-side process, which seems weird.

Question: is is possible to pass arbitrary data with a Content Delivery API request?  So, for example, could I tack on a querystring argument, like --

&customer_type=vip

-- then write a custom Visitor Group that reads this from the API request?