Long-lived access token #16453

awarecan · 2018-09-06T06:27:15Z

Description:

Implement long-lived access token back end logic

Allow create refresh_token with different access_token_expiration,
Add client_name, client_icon fields
Add token_type, normal, system or long_lived_access_token
Each such client_id can only have one long_lived_access_token type refresh_token, each such refresh_token can only have one active access_token.

Send websocket command auth/long_lived_access_token will create or refresh a long-lived access token for current user. Access token will not be saved in Home Assistant. User need to record the token in secure place.

{
    "id": 11,
    "type": "auth/long_lived_access_token",
    "client_id": "gps_logger",
    "client_name": "GPS Logger",
    "client_icon": null,
    "lifespan": 365
}

Result will be a long-lived access token:

{
    "id": 11,
    "type": "result",
    "success": true,
    "result": "ABCDEFGH"
}

To use access token, put it in HTTP Authorization Header, for example

curl -H "Authorization: Bearer ABCDEFGH" http://hassbian.local:8123/api

Related issue (if applicable): fixes back-end part #15195

Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/developers.home-assistant#82

Example entry for `configuration.yaml` (if applicable):

Checklist:

The code change is tested and works locally.
Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

Documentation added/updated in home-assistant.github.io

If the code does not interact with devices:

Tests have been added to verify that the new code works.

balloob · 2018-09-06T08:15:53Z

homeassistant/auth/__init__.py

+                'refresh tokens')
+
+        if (token_type == models.TOKEN_TYPE_LONG_LIVED_ACCESS_TOKEN and
+                (client_id is None or client_id.lower().startswith(


I think instead we should just enforce client_id is None

balloob · 2018-09-06T08:16:19Z

homeassistant/auth/__init__.py

+            raise ValueError('Client_id is not allowed start with http:// or '
+                             'https:// for long-lived access token')
+
+        if token_type == models.TOKEN_TYPE_LONG_LIVED_ACCESS_TOKEN:


I think that this is a weird check. We shouldn't enforce this but instead leave this up to the user.

Current is
1 client_id : 1 refresh_token : 1 long-lived access_token

Did you want to change to
1 client_id : m refresh_token : m long-lived access_token

balloob · 2018-09-06T08:18:50Z

homeassistant/auth/auth_store.py

+            client_name: Optional[str] = None,
+            client_icon: Optional[str] = None,
+            token_type: str = models.TOKEN_TYPE_NORMAL,
+            access_token_expiration: Optional[timedelta] = None) \


Isn't this one always passed in and so doesn't have to be optional? I think it's a security concern if expiration defaults are applied whenever we load a refresh token.

Current workflow, the normal login flow, did not pass in access_token_expiration

Default value will be set in the lowest level of access_token creation. if user pass in None, this field would not be set in **kwargs, therefore the access_token will carry on default expiration value, 30 minutes

This should not live in auth_store but in auth_manager, as that's where the business logic should live.

balloob · 2018-09-06T08:21:40Z

homeassistant/auth/auth_store.py

@@ -178,6 +195,31 @@ def __init__(self, hass: HomeAssistant) -> None:

        return found

+    @callback
+    def async_mutate_refresh_token(


I am thinking now if all this hassle is even necessary.

If we just never tell the user the refresh token, they can never get a second access token. If our API endpoint just returns the access token, this is no longer our concern.

And if it's not our concern, we don't have to enforce single access token, we don't have to re-generate JWT tokens. It makes everything a lot simpler. We can still keep type, as it helps showing the user what's going on.

We only use refresh_token as a container to save client information in this case. It never returns back to user. But I am imaging there is "refresh" or "regenerate" button in UI to allow user get a new access token, at the same time revoke previous issued

Back to the above comment in, if we have 1:m for client_id and refresh_token, then this enforce is unnecessary, otherwise, we still need a method to either recreate refresh_token or mutate jwt_key

I think it's easier to solve the regenerate case by removing old refresh token and generate a new refresh and access token with same client id/icon. auth_store is already growing a lot and this should be kept as simple as possible.

So I suggest we do without this method.

homeassistant/auth/__init__.py

houndci-bot · 2018-09-10T08:41:18Z

homeassistant/auth/auth_store.py

 from homeassistant.core import HomeAssistant, callback
 from homeassistant.util import dt as dt_util

-from . import models
+from . import models, util


'.util' imported but unused

balloob · 2018-09-10T11:32:46Z

homeassistant/auth/__init__.py

+                'refresh tokens')
+
+        if (token_type == models.TOKEN_TYPE_LONG_LIVED_ACCESS_TOKEN and
+                (client_id is None or client_name is None)):


client_id should be None. Client ID is what is used when a user generates a token via an external client. When creating a long lived token, they use the UI and no external client is involved.

balloob · 2018-09-10T11:33:45Z

homeassistant/auth/__init__.py

+            for token in list(user.refresh_tokens.values()):
+                if (token.client_id == client_id and token.token_type ==
+                        models.TOKEN_TYPE_LONG_LIVED_ACCESS_TOKEN):
+                    # Each client_id can only have one long_lived_access_token


Client ID should always be None. I think that this check can be removed.

homeassistant/auth/__init__.py

balloob · 2018-09-10T15:59:29Z

homeassistant/auth/__init__.py

+                'System generated users can only have system type '
+                'refresh tokens')
+
+        if not user.system_generated and \


You can collapse this if-statement in the previous one:

if user.system_generated != (token_type == models.TOKEN_TYPE_SYSTEM): raise ValueError(…)

* Allow create refresh_token with specific access_token_expiration * Add token_type, client_name and client_icon * Add unit test * Add websocket API to create long-lived access token * Allow URL use as client_id for long-lived access token * Remove mutate_refresh_token method * Use client name as id for long_lived_access_token type refresh token * Minor change * Do not allow duplicate client name * Update docstring * Remove unnecessary `list`

qingdujun · 2018-09-26T03:22:26Z

Hi, Help Me! Is the content sent incorrectly?

I have successfully authenticated, but I want a long-term token.

...
As you can see.
...

{"type": "auth_required", "ha_version": "0.77.3"}

var v = {type: 'auth', access_token: token};

ws.send(JSON.stringify(v));

{"type": "auth_ok", "ha_version": "0.77.3"}

Ok, It was all successful before here.
...

THEN (error)
...

SEND

var long_lived = {id:'11', type: 'auth/long_lived_access_token', 
client_name: 'GPS Logger', client_icon:null, lifespan:365};

ws.send(JSON.stringify(long_lived));

RECV

{"id": 11, "type": "result", "success": false, "error": {"code": 4, "message": "Unknown command."}}

MartinHjelmare · 2018-09-26T03:55:43Z

Please open an issue. Closed PRs should not be used for support or bug reports.

awarecan added 4 commits September 5, 2018 00:05

Allow create refresh_token with specific access_token_expiration

0d85e29

Add token_type, client_name and client_icon

312cda5

Add unit test

fa01a29

Add websocket API to create long-lived access token

ad0189c

homeassistant added cla-signed integration: auth core labels Sep 6, 2018

ghost assigned awarecan Sep 6, 2018

ghost added the in progress label Sep 6, 2018

balloob reviewed Sep 6, 2018

View reviewed changes

homeassistant/auth/__init__.py Outdated Show resolved Hide resolved

Allow URL use as client_id for long-lived access token

19256ac

homeassistant added the cla-signed label Sep 6, 2018

houndci-bot reviewed Sep 10, 2018

View reviewed changes

Remove mutate_refresh_token method

463b6ed

awarecan force-pushed the long-lived-access-token branch from a48df39 to 463b6ed Compare September 10, 2018 08:42

homeassistant added the cla-signed label Sep 10, 2018

balloob reviewed Sep 10, 2018

View reviewed changes

Use client name as id for long_lived_access_token type refresh token

eeb4ef7

balloob reviewed Sep 10, 2018

View reviewed changes

homeassistant/auth/__init__.py Outdated Show resolved Hide resolved

balloob reviewed Sep 10, 2018

View reviewed changes

awarecan added 3 commits September 10, 2018 09:03

Minor change

1e52bdb

Do not allow duplicate client name

80b26ef

Update docstring

26126fb

awarecan mentioned this pull request Sep 11, 2018

Add long-lived access token home-assistant/developers.home-assistant#82

Merged

Remove unnecessary list

4dd9f59

ghost assigned balloob Sep 11, 2018

balloob approved these changes Sep 11, 2018

View reviewed changes

balloob merged commit 9583947 into home-assistant:dev Sep 11, 2018

ghost removed the in progress label Sep 11, 2018

balloob mentioned this pull request Sep 11, 2018

Fix typo #16556

Merged

balloob added this to the 0.78.0 milestone Sep 11, 2018

balloob added the cherry-picked label Sep 11, 2018

zachowj mentioned this pull request Sep 14, 2018

Connection class doesn't resubscribe to events if event_type empty home-assistant/home-assistant-js-websocket#57

Closed

balloob mentioned this pull request Sep 17, 2018

0.78.0 #16666

Merged

rytilahti mentioned this pull request Sep 20, 2018

Update authorization type for new version home-assistant. mueslo/openwrt_hass_devicetracker#4

Closed

home-assistant locked as resolved and limited conversation to collaborators Sep 26, 2018

awarecan deleted the long-lived-access-token branch March 12, 2019 06:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Long-lived access token #16453

Long-lived access token #16453

awarecan commented Sep 6, 2018 •

edited

Loading

balloob Sep 6, 2018

balloob Sep 6, 2018

awarecan Sep 6, 2018

balloob Sep 6, 2018

awarecan Sep 6, 2018

balloob Sep 10, 2018

balloob Sep 6, 2018 •

edited

Loading

awarecan Sep 6, 2018

balloob Sep 10, 2018

balloob Sep 10, 2018

houndci-bot Sep 10, 2018

balloob Sep 10, 2018

balloob Sep 10, 2018

balloob Sep 10, 2018

qingdujun commented Sep 26, 2018 •

edited

Loading

MartinHjelmare commented Sep 26, 2018

Long-lived access token #16453

Long-lived access token #16453

Conversation

awarecan commented Sep 6, 2018 • edited Loading

Description:

Example entry for configuration.yaml (if applicable):

Checklist:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

balloob Sep 6, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qingdujun commented Sep 26, 2018 • edited Loading

MartinHjelmare commented Sep 26, 2018

awarecan commented Sep 6, 2018 •

edited

Loading

Example entry for `configuration.yaml` (if applicable):

balloob Sep 6, 2018 •

edited

Loading

qingdujun commented Sep 26, 2018 •

edited

Loading