@@ -156,8 +156,26 @@ Client credentials tokens are useful in some circumstances (like
156156testing that the token endpoint works), but to take advantage of all
157157the features of our server we want to be able to create tokens for
158158users. To get a token on behalf of a user of our app we need to be
159- able to authenticate the user, which means we need a browser, so we
160- might go the whole hog and create a test application.
159+ able to authenticate the user. If you were watching the logs carefully
160+ when the app started up you would have seen a random password being
161+ logged for the default Spring Boot user (per the
162+ http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#boot-features-security[Spring
163+ Boot User Guide]). You can use this password to get a token on behalf of the user with id "user":
164+
165+ ```
166+ $ curl acme:acmesecret@localhost:8080/oauth/token -d grant_type=password -d username=user -d password=...
167+ {"access_token":"aa49e025-c4fe-4892-86af-15af2e6b72a2","token_type":"bearer","refresh_token":"97a9f978-7aad-4af7-9329-78ff2ce9962d","expires_in":43199,"scope":"read write"}
168+ ```
169+
170+ where "..." should be replaced with the actual password. This is
171+ called a "password" grant, where you exchange a username and password
172+ for an access token.
173+
174+ Password grant is appropriate for a native or mobile application, and
175+ where you have a local user database to store and validate the
176+ credentials. For an app with "social" login, like ours, you need a
177+ browser to handle redirects and render the user interfaces from the
178+ external providers.
161179
162180== Creating a Client Application
163181
0 commit comments