Releases: decomplexity/SendOauth2
Additional operands for GoogleAPI for .json management
V4.1.0 introduces two new optional operands for the invocation of both the standard PHPMailer email application and for the complete replacement of a PHPMailer application by the wrapper front-end. There operands allow the developer to specify a name for the .json credentials file and/or whether the wrapper should dynamically build this .json file or use an already-built one, created either by Google (its standard download) or by the developer.
Adds support for GoogleAPI - OAuth2 and Google service accounts
SendOauth2 V4.0.0 supports both OAuth2 and Basic authentication for both Microsoft 365 Exchange email and Google Gmail.
Microsoft support is for Microsoft 365 accounts using Graph V1 with the V2 authentication and authorization endpoints.
Google support is for any non-legacy version of Gmail.
Client secrets and X.509 certificates are supported for Microsoft.
TheLeague's Gmail provider only supports client secrets (and only for authorization_code grant).
Google's Gmail API supports client secrets for authorization_code grant and X.509 certificates for client_credentials grant (aka Google 'service accounts'), and both are supported by the wrapper. Google's use of .json credentials files is out of kilter with PHPMailer's established client authentication mechanism, so the wrapper creates these files automatically (although Google's own files can optionally be used instead)
For Microsoft, both authorization_code grant and client_credentials (i.e. application) grant flows for SMTP are supported.
For the Google API, both authorization_code grant and client_credentials (service accounts) grant for SMTP are supported (see github repository/library googleapis/google-api-php-client)
TheLeague's Google Gmail provider only supports authorization_code grant, and this is supported by the wrapper.
Where the provider or client supports them, both $_SESSION 'state' exchange and PKCE code exchange are implemented automatically by the wrapper to forestall CSRF attacks during authorization_code flow.
SendOauth2 can provide automatic renewal of refresh tokens for Microsoft 365; this is normally unnecessary for Gmail as Google refresh tokens do not life-expire by default.
Updates .json to include Google's API
Google's API for Gmail supports their version of client_credentials ("service accounts") as well as authorization_code. The .json update 'requires' the API code for future use by SendOauth2 in V4.
Adds support for MSFT client_credentials and X.509 certificates
For Microsoft 365, adds support for client_credentials grant for SMTP and X.509 certificates.
No modifications to PHPMailer code are needed
Create and use a 'state' FILE instead of $_SESSION in SendOauth2D
A 'nonce' state token is used between the first and second passes of SendOauth2D to pre-empt a CSRF vulnerability.
But an intermittent 'invalid state' was occurring on first pass of SendOauth2D where $state set does not agree with that stored in $_SESSION. It appeared that session_id() was responding empty even though browser had a suitable PHPSESSID cookie. A session_write_close() was added just before the first pass ended with a call to provider's authentication to try to prevent a possible race condition occurring (SendOauth2D - via SendOauthD-invoke - is re-entrant). But this was not always effective when the browser had multiple tabs open, so instead of using a 'state' set in $_SESSION, SendOauth2D now writes the state to a local file on the first pass, reads it on the re-entrant pass and then deletes the file.
Provider oauth2-google version dependency increased in json
oauth2-google version now >=4.0.0 Update oauth2-google version from >=3.0.4 to >=4.0.0 as my bash shell PHP version is now upgraded to 7.3 and not the previous 5.6 (the http version was fine at 7.3.5)
Namespace and changes for autoload
v1.0.3 Update README.md
Packagist rel. with Composer autoload and amended PHP version
v1.0.2 Remove 2 x providers