This is a tricky nuance: Social Provider integration is not actually authentication.  This is why people are often so confused about OAuth: OAuth is *not* an authentication/single-sign-on protocol.  It is an _authorization_ protocol that allows one party (Stormpath customer) to be granted _access_ to account data stored by another party (e.g. Google or Facebook).

Facebook will often ask the end-user to authenticate _first_ to assert that the actual correct person is interacting with Facebook.  Once asserted, the end-user will tell Facebook "Go ahead, allow 3rd party X (Stormpath customer) to access my Account data".

That authentication happens first before the user grants authorization is an implementation detail / side effect - authentication is not the primary purpose of OAuth.  It is the sharing of - the 'authorizing of' the account data - that is why OAuth exists.

That is, Stormpath does not authenticate the end-user: instead, Stormpath requests (on behalf of our customer of course) to be granted _access_ to the social Account.  It is assumed that the end-user authenticates at some time to grant access, but again, that is a side-concern.

This nuance is clearer when a provider supports OAuth offline access:  the end-user doesn't have to be currently authenticated/logged-in at all - Stormpath can talk to Facebook directly (if authorized) without the end-user ever logging in.  This is a reflection that OAuth's primary function is *authorization*, and not authentication.

SAML by comparison was *designed* specifically for Single Sign On, and it is better suited for that purpose.

Anyway, this is all probably more than what you wanted to hear ;)  My point in all of this is that 1) we should rename the method to reflect what is really going on, and so that 2) we don't propagate the (unfortunate) mis-representation that OAuth is somehow an authentication protocol (because it isn't).

So, that being said, let's change this signature to the following:

    ProviderAccountResult getAccount(ProviderAccountRequest request);

There should be a `Providers` helper class so the SDK end-user can create the request for different providers easily.  For example:

    Providers.GOOGLE.accountRequest().setCode("4/2Dz0r7r9oNBE9dFD-_JUb.suCu7uj8TEnp6UAPm0").build();

this would result in the `ProviderAccountRequest` instance to use to invoke `getAccount`.

`ProviderAccountResult` is necessary instead of just returning the `Account` directly, because we need to be able to tell the SDK user if the account returned was newly created in Stormpath (i.e. as a result of obtaining it for the first time from the provider), or if it existed already.  This information might be useful for them:

    ProviderAccountResult result = application.getAccount(providerAccountRequest);
    if (result.isNewAccount()) {
        //do something
    }

If the caller doesn't care about this status, they can just directly call result.getAccount() and it should return an `Account` instance.

Here's a quick example putting all of these things together:

    Account account = application.getAccount(Providers.GOOGLE.accountRequest()
            .setCode("4/2Dz0r7r9oNBE9dFD-_JUb.suCu7uj8TEnp6UAPm0").build()).getAccount();

or if you need to know if the account was newly created as a result of the request:

    ProviderAccountResult result = application.getAccount(Providers.GOOGLE.accountRequest()
            .setCode("4/2Dz0r7r9oNBE9dFD-_JUb.suCu7uj8TEnp6UAPm0").build());

    if (result.isNewAccount()) {
        //do something
    }

I hope that helps!