| | 17 | === Standard use case - keep your OSM password private === |
| | 18 | The standard use case in OSM for OAuth is to keep your OSM password more private than with Basic Authentication. |
| | 19 | |
| | 20 | OAuth has two major advantages over Basic Authentication: |
| | 21 | 1. Your OSM password doesn't have to be saved in clear text in the JOSM preferences file. |
| | 22 | 2. Your OSM password has to be transferred '''only once''' over the Internet, in contrast to basic authentication where your OSM password is trasferred as part of every request sent from JOSM to the OSM server. |
| | 23 | |
| | 24 | {{{ |
| | 25 | #!html |
| | 26 | <p style="background-color:rgb(253,255,221);padding: 10pt; border-color:rgb(128,128,128);border-style: solid; border-width: 1px;"> |
| | 27 | <strong>Warning!</strong><br/> |
| | 28 | Currently, the OSM server doesn't offer a secure communication channel. Even if you use OAuth your password is therefore transferred <strong>once in clear text</strong> over the Internet. <strong>Do not use a valuable password</strong> until the OSM server provides a secure communication channel (HTTPS). |
| | 29 | </p> |
| | 30 | }}} |
| | 31 | |
| | 32 | In OAuth terminology, a JOSM user authorises JOSM to access the OSM server on his behalf. During the authorisation process he never has to enter his OSM password into a JOSM dialog if he or she doesn't fully trust JOSM (unless he wants to for convenience reasons [wiki:/Help/Dialog/OAuthAuthorisationWizard#FullyAutomaticAuthorisation see here]). Rather, the OSM server issues an Access Token which JOSM presents to the OSM server when it uploads data on behalf of the user. Access Tokens don't reveal the users password and they can be revoked at any time. |
| | 33 | |
| | 34 | === Advanced use case - delegate access to fellow mappers === |
| | 35 | |
