feat(auth): refactor auth configuration logic

[Convly]

What does it do?

Simplifies the auth configuration by flattening the properties.

Basically

strapi({
  baseURL: '...',
  auth: {
    strategy: 'api-token',
    options: {
      token: '<token>'
    }
  }
})

becomes

strapi({
  baseURL: '...',
  auth: '<token>'
})

Why is it needed?

Improve the developer experience when using the SDK

How to test it?

See example above, it should work the same for the undocumented users-permission provider

[innerdvations]

LGTM but haven't tested it out

[innerdvations]

Even better now :)

I will try to test it tomorrow, not sure I have time today

[jhoward1994]

Looks good 👍🏻

I just can't get my head round how you would provide a different auth provider? Or even how auth providers would differ now if the auth property is just a string token?

[Convly]

Looks good 👍🏻

I just can't get my head round how you would provide a different auth provider? Or even how auth providers would differ now if the auth property is just a string token?

The idea was to simplify things while we only have one authentication method while keeping some space and flexibility in case we want to add something later.

For instance if we end up having multiple providers people can use, we could introduce an authStrategy property and auth would be "unknown" to represent whatever param the strategy expects.

Another option in the future that this solution allows, is to keep the auth to api token forever and delegate custom auth to extensions/plugins (interacting with an auth API to switch auth strategies)

To summarize this abstract the current auth API to the minimum/simplest so that we have more option in the future and we don't limit ourselves with breaking changes