Confirmed users
591
edits
(→OAuth2: Move OAuth outside the <incomingServer>, to avoid repetition) |
(→OAuth2: Scope) |
||
Line 278: | Line 278: | ||
</incomingServer> | </incomingServer> | ||
</emailProvider> | </emailProvider> | ||
<oAuth2> | <oAuth2> | ||
<issuer>login.yahoo.com<issuer> | <issuer>login.yahoo.com</issuer> | ||
<scope>mail-w<scope> | <scope>mail-w</scope> | ||
<authURL>https://api.login.yahoo.com/oauth2/request_auth</authURL> | <authURL>https://api.login.yahoo.com/oauth2/request_auth</authURL> | ||
<tokenURL>https://api.login.yahoo.com/oauth2/get_token</tokenURL> | <tokenURL>https://api.login.yahoo.com/oauth2/get_token</tokenURL> | ||
<oAuth2> | </oAuth2> | ||
</pre> | </pre> | ||
Line 289: | Line 290: | ||
Note that there are two `<authentication>` elements. This allows a fallback, in case a client does not support OAuth2 or does not have a client key for this OAuth2 issuer and therefore cannot authenticate with this issuer. | Note that there are two `<authentication>` elements. This allows a fallback, in case a client does not support OAuth2 or does not have a client key for this OAuth2 issuer and therefore cannot authenticate with this issuer. | ||
The scope is difficult. If we set up email, address book, calendar, and webdav, we do *not* want the user go have to go through 4 authentication processes. Yet, a provider might use different scopes for email and calendar, and that is in line with the OAuth2 spec. The solution is to combine several scopes, using [https://tools.ietf.org/html/rfc6749#section-3.3 spaces as separator], in a single auth request. However, it is reported that this fails for some providers. If really necessary, we could add it as optional parameter `<authentication scope="mail-w">OAuth2</authentication>`, while still defaulting to `<oAuth2>.<scope>`, but that would cause the above mentioned issue of requiring several authentication processes. | |||
= TODO = | = TODO = |