Idea for a new specification that can be used to store browser authentication information. Authorization Storage (pseudonym)

[aoisensi]

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.

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.

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

You can also delete it.

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.

const url = 'https://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!

[annevk]

Thank you for creating this proposal. I would suggest reaching out to https://wicg.io/ to see if there's interest in taking this further. Having said that, there was something similar to this called Token Binding and that ultimately didn't really go anywhere.

[aoisensi]

@annevk Thank you for leading. I will post to discourse.

[aoisensi]

https://discourse.wicg.io/t/idea-for-a-new-specification-that-can-be-used-to-store-browser-authentication-information/5138