Add ability for the CLI to "logout"

[haishengwu-okta]

> okta login
Okta Org already configured: https://dev-xxxxxx.okta.com

And I don't see a logout command.

[mraible]

Just curious, why do you want to logout?

[haishengwu-okta]

@mraible I'd like to login into another okta tenant. also intuitively every app has login would have logout. :D

[bdemers]

Ahh, ideally calling okta login should over right your config which would take care of this scenario.

If we add a logout command we would probably also want to invalidate the token used, which may or may not be what the user things will happen.

For the short term just delete ~/.okta/ and call okta login again.

This should be something we can fix in the next release.

[mraible]

Maybe it should be like the Cloud Foundry CLI? You can deploy CF anywhere, so you have to specify the API when logging in.

cf login -a api.run.pivotal.io

I could see how it might be nice to have multiple orgs listed in ~/.okta/ and you can choose which one to log in to. Something like:

okta login dev-133320.okta.com

[bdemers]

I like this idea. 🤔 If I had two orgs configured. I'm guessing I would use them something like:

okta apps create --org dev-123456.okta.com

(or something like that)

But what should happen if I don't specify the URL (assuming I still have two orgs configured)?

[haishengwu-okta]

okta apps create --org dev-123456.okta.com

seems make thing complicated. I feel good enough I can login/logout and other command just work on context after login.

I have okta dev env which has something in the .okta directory as well. I'd assume you meant to delete ~/.okta/okta.yaml. One more question: looks like okta.yaml is plain text file hence the api token. Are we considering encrypt it?

[mraible]

If you only have one org in ~/.okta/okta.yaml, everything should work as it currently does. This is how Heroku does it. If you only have a one Heroku remote, you don't need to specify --app (or --remote). For example, here's my remotes on a repo:

➜  okta-angular-spring-boot-docker-example git:(main) git remote -v
docker  https://git.heroku.com/pacific-everglades-63339.git (fetch)
docker  https://git.heroku.com/pacific-everglades-63339.git (push)
heroku  https://git.heroku.com/bootiful-angular.git (fetch)
heroku  https://git.heroku.com/bootiful-angular.git (push)
jib https://git.heroku.com/stormy-journey-87996.git (fetch)
jib https://git.heroku.com/stormy-journey-87996.git (push)
origin  git@github.com:oktadeveloper/okta-angular-spring-boot-docker-example.git (fetch)
origin  git@github.com:oktadeveloper/okta-angular-spring-boot-docker-example.git (push)

If I run heroku config on it, it prompts me:

➜  okta-angular-spring-boot-docker-example git:(main) heroku config
 ›   Error: Multiple apps in git remotes
 ›     Usage: --remote heroku
 ›        or: --app bootiful-angular
 ›     Your local git repository has more than 1 app referenced in git remotes.
 ›     Because of this, we can't determine which app you want to run this command against.
 ›     Specify the app you want with --app or --remote.
 ›     Heroku remotes in repo:
 ›     pacific-everglades-63339 (docker)
 ›   bootiful-angular (heroku)
 ›   stormy-journey-87996 (jib)
 ›
 ›     https://devcenter.heroku.com/articles/multiple-environments

However, if I delete my docker and jib remotes, it works.

➜  okta-angular-spring-boot-docker-example git:(main) git remote rm docker
➜  okta-angular-spring-boot-docker-example git:(main) git remote rm jib
➜  okta-angular-spring-boot-docker-example git:(main) heroku config
=== bootiful-angular Config Vars
ALLOWED_ORIGINS:               http://localhost:4200,https://rocky-dawn-37186.herokuapp.com
APP_BASE:                      notes-api
...

[bdemers]

@haishengwu-okta we would still need to store a secret key to handle encryption. In the future, we may be able to support doing something with a more temporary access token. But there is a bit of a chicken & egg problem with that right now.

[haishengwu-okta]

@bdemers I was thinking that some of application I'm using will ask for a passphrase to store some secret (like token or password) I could choose none which means token/password will store as plain text or I have to choose a passphrase (which I need to remember myself) so that the application can store encrypted the token/password. I'm actually not entire sure how it works behind scene (what techniques got involved) but I feel a bit better as enduser that I was aware that there is token stored somewhere (whether encrypted or not).

If we don't add encryption shortly, would be better to tell user that we store the api token at okta.yaml as plain text? At lease they are aware the risk of leaking api token.

[haishengwu-okta]

For login interface, I'm thinking something like

> okta login
if okta.yaml exists and only one, then login (existing behavior)
if there are multiple tenants, ask for user's choice
if none in okta.yaml, ask for org url and token (existing behavior)

> okta login xyz.okta.com
if exists in okta.yaml, login
otherwise, ask for token

> okta logout
ask for user to confirm to wipe out everything or particular one from in okta.yaml
fail if never login

> okta logout xyz.okta.com
wipe out this specific tenant from okta.yaml

Seems either making login flexible or adding logout would solve my personal problem. ;)

[bdemers]

Secret stores (for example the mac keychain) are not consistent between OS's, and may not exist at all for some. Using environment variables should work as well, for scripting, or docker environments. In those cases the user would be in control of how those vars are set.

For now though, we can add a note.