# Authorization Code Flow

**URL:** https://forum.solidproject.org/t/authorization-code-flow/772
**Category:** Solid App Development FAQs
**Created:** [December 3, 2018, 4:12pm UTC](https://forum.solidproject.org/t/authorization-code-flow/772 "2018-12-03T16:12:03Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![michielbdejong](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/michielbdejong/32/195_2.png) [@michielbdejong](https://forum.solidproject.org/u/michielbdejong)
#### Post date: [December 5, 2018, 10:18am UTC](https://forum.solidproject.org/t/authorization-code-flow/772/4 "2018-12-05T10:18:40Z")

</div>

The token proves to the storage that the app acts on behalf of the user. So even if you run a server-side or command-line app, it will use this login token to communicate with the storage.

There is another way to do this: your app server should host a foaf profille, and in order to “issue” a token to that app, the user edits the `.acl` file on the storage to list that from now on, not only the user themselves, but also [https://cool-app.com/foaf#card](https://cool-app.com/foaf#card) has access to that folder. Then, instead of presenting a proof-of-id of the user themselves, the app provides its own proof-of-id, and the ACL on the storage pod allows it access.

As far as I know, there is currently no way to issue bearer tokens in the traditional sense. Some more discussion about this here: [Read-only or sub-folder OIDC scopes?](http://forum.solidproject.org/t/read-only-or-sub-folder-oidc-scopes/767/4?u=michielbdejong)

---

_[View the full topic](https://forum.solidproject.org/t/authorization-code-flow/772)._