[whatwg/fetch] Idea for a new specification that can be used to store browser authentication information. Authorization Storage (pseudonym) (#1150)

# First
I am Japanese, and I do not have good English.

If you can read Japanese, please read this original.

https://zenn.dev/aoisensi/scraps/a869e8095581ae

# Current

Currently, there are two ways to send authentication information when using `xhr` or `fetch` by web applications.

`Cookie` and `Authorization` header.

I think `Cookie` is more commonly used now.

Because, if you use Auth method, you should save token to `Local Storage` and it does not have secure.

https://www.rdegges.com/2018/please-stop-using-local-storage/

However, using `Cookie` is not a panacea.

For example, when you create an application such as `TweetDeck` that exchanges data from multiple accounts on a single screen, you have to link multiple accounts in the session information and specify which account the request is from each time you hit the API, which is not very smart.

I actually analyzed the communication content of `TweetDeck`, and it seems to be implemented in such a way.

The Auth method allows the token to be specified in `JavaScript`, which simplifies the implementation, but has security flaws.

# Implementation

I came up with `Authorization Storage`, which solves this problem.

`Authorization Storage` is a storage area that comes with the browser like `Local Storage` and `Session Storage`.

_I will write the code afterwards, but since it is a random implementation I came up with, I think there will be problems._

`Authorization Storage` can store strings in key-value format per domain like `Local Storage` and `Session Storage`.

```javascript
authStorage.setItem('user1', 'Bearer ThiSisRanDoMeGeNerateDToken');
```

However, it is not possible to load __values__ from the `JavaScript`.

Instead, the list of stored keys can be loaded.

```javascript
console.log(authStorage.keys()); // ['user1']
```

You can also delete it.

```javascript
authStorage.removeItem('user1'); // remove user1 token
```

So how do we use the data we can't read?

It can be used when using `xhr` or `fetch`.

```javascript
const url = 'https://api.example.com/api/1.0/articles';
const userId = 'user1';
await fetch(url, {authKey: userId});
```

The above `fetch` request will contain the `Authorization: Bearer ThisSisRanDoMeGeNerateDToken` header.

Also, if the `Request` can be retrieved using this function, the `Authorization` header should not be accessible.

(Is it possible to read headers after `fetch` or `xhr` is executed? I don't know, I'm not expert.)

# Conclusion

Implementing this mechanism would allow for secure and flexible storage of tokens.

Please feel free to comment on counterarguments and problems.

Thank you for taking the time to read this long article.

DeepL awesome!


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1150