Log In to the Marketplace

TL;DR — Install the bjs CLICommand-line interface, a tool you drive by typing commands into a terminal rather than clicking buttons. and run bjs login. It saves a sessionYour saved logged-in state: the tokens and user info the CLI keeps on disk so later commands know who you are. in ~/.bjs/config.json. The rest of the lesson shows how the OAuthAn open standard for letting a tool act on your behalf by getting your approval in a browser, without ever seeing your password. device-code flow sends your identity back to a terminalThe text window where you type commands and read their output, instead of clicking buttons. that runs no server. Skip this if bjs whoami already prints your email and you know how the OAuth device authorization grantThe OAuth flow (RFC 8628) for tools that can't host a browser: show the user a code, send them to a web page to approve, then poll for the result. works.

This course is a tour of bjs, the command line for the BabylonJS Market. You use it to log in, browse the catalog, download assets, and submit your own components. Almost all of it needs an account that the CLI can prove is yours. So you start at login.

You run bjs login. A browser tab opens. You click approve and switch back to the terminal. It already knows your email. No password ever reached the CLI. The CLI never ran its own web server to catch the browser's reply. It never asked you to paste in a key.

So how did your identity get back to a tool that can't receive messages? The terminal can send requests out. But nothing can send a message in to it. The answer is a login process called the OAuth 2.0 Device Authorization Grant. Once you see how it works, you understand the move behind every account command in this course.

But first, let's look at the two tools you'll use, and the one rule that tells them apart.

The two tools: bjs and arcade

The BabylonJS Market is a working library of game code. It has player movement, health and damage, scoring, and pickups. These are components that other developers built and published. Two command-line tools move you through it.

The first is bjs, the member CLI. It lives in the @babylonjsmarket/cli packageA unit of code published to npm under a name, that you install into a project and import.. That @org/name shape just means the package is published under the babylonjsmarket organization. bjs handles everything that touches your account or other people's published work. That means logging in, browsing the catalog, downloading assets, and submitting your own componentHere, a reusable game behavior (a piece of ECS game code), not a UI/React component.. You install it with npmNode's package installer; the command that fetches and installs packages. You already have it if you've installed Node., Node's package installer. You already have npm if you've set up Node. Install bjs globally so its command works in any folder:

npm install -g @babylonjsmarket/cli
bjs --version

The second is arcade. It ships inside the @babylonjsmarket/arcade frameworkA package that gives your code a structure to fill in — you write pieces that plug into the shapes it defines.. So once you have a project, there's nothing extra to install. You reach it as npm create @babylonjsmarket/arcade and arcade eject. bjs talks to the marketplace. arcade works on the files already in your own project. It scaffolds a new game. It also copies the framework's built-in component source into your project's src/ folder, where your source code lives. Those components are reusable game behaviors.

That gives you the rule of thumb for the whole course: your account and other people's published work go through bjs; rearranging files in your own project goes through arcade.

Here's the full bjs command set, and where you meet each one in this course:

Everything except login, logout, and whoami needs you signed in. So login is the first step. It's also the part that works in a surprising way.

Why the CLI uses a device-code login

A CLI is a bad place to type a password. You would hand your marketplace login to a command-line program. That program would then have to store it. And the marketplace would have to trust the program never to leak it. The whole industry walked away from that years ago.

The modern answer is OAuth. You approve the tool in a browser you already trust. The tool never sees your password. It only gets a token that the server hands back. This works well for web apps, because they have a URL the browser can redirect to.

A terminal has no URL. So there's nowhere for the browser to send the result. This is the exact case the Device Authorization Grant (RFC 8628) was made for. It's the flow OAuth uses for smart TVs, game consoles, and command-line tools. Any device that can reach the internet but can't receive a redirect can use it. Here's how bjs login runs that flow.

The first thing it does is check whether you're already signed in. If a session exists, login stops early — it tells you who you are and quits. That's why running bjs login twice never starts a second login.

When there's no session, the flow begins. The CLI makes a single request to the marketplace for a device codeA long secret string the server issues to the CLI at the start of login, which the CLI quotes back on every poll to claim its tokens., and gets back a small bundle of fields. Two of them do the work you can see. One is the user_code: the short code the CLI prints in yellow for you to type. The other is the verification_uri: the page it sends you to. The CLI opens that page for you — it prefers the variant that already has your code filled in, and falls back to the plain page if that variant isn't offered. Notice what the CLI does not do. It never starts a server, never claims a port, and never builds its own login screen. It reuses the login UI already on the marketplace site. In the terminal you see something like this:

$ bjs login
Starting authentication flow...

To authenticate, enter this code:
WDJB-QXMP

On this page:
https://babylonjsmarket.com/device

Opening browser...

Waiting for authentication...

You type WDJB-QXMP on the page, sign in if you need to, and approve. On the server, that login is now marked approved. It's tied to the device code that only your terminal holds. But the terminal still doesn't know. Nothing has been sent to it.

The poll loop that waits for approval

This is the key idea. The CLI can't be told that you approved, because there's no address to send that message to. So it asks again and again, on a fixed interval: is it approved yet? Each time, it sends back the device_code it received at the start. That code is the secret that proves this poll belongs to this login. This repeated asking is pollingAsking the server the same question on a fixed interval until the answer changes, instead of waiting to be told., and it drives the whole flow.

On each pass, the CLI waits a short interval, then sends the device code back to the marketplace and asks for a token. Most of the time the server answers with a not yet. The CLI reads that answer using a small set of words the standard defines:

• authorization_pending — you haven't approved yet. Keep waiting. This is the normal gap between polls.
• slow_down — you're asking too fast. The CLI adds five seconds to the interval and keeps going.
• expired_token — you took too long and the device code has died. Run bjs login again to get a fresh one.
• access_denied — you or someone else hit deny on the page. The CLI stops.

The moment you approve, the next poll comes back ok. Now the server hands over what you need. First is an access tokenThe credential the CLI sends with each request to prove who you are; it expires after a while.. Every future request carries it to prove it's you. Second is usually a refresh tokenA longer-lived credential the CLI uses to get a fresh access token without making you log in again.. This is a longer-lived credential, saved for an auto-renew feature that isn't wired up yet. For now, when the access token expires, you just run bjs login again. The CLI saves both tokens. Then it makes one authenticated call to fetch your email and name. Finally it prints the line you came for:

Authentication successful!

Logged in as: you@example.com
Authentication data saved to ~/.bjs/config.json

Your identity never traveled to the terminal. The terminal went and collected it. It could do this because it held a secret that the browser approval unlocked. So here's the answer to the opening puzzle. A tool that can't receive messages doesn't need to, as long as it keeps asking.

The session is a file on disk

That last line tells you where everything landed: ~/.bjs/config.json, in your home directory. Your tokens and account info now live there as saved data. This saved data is your session. There's nothing live or mysterious about being logged in. It's just a file the next command reads.

bjs whoami shows this clearly. The whole command does one thing: it reads that file back and checks that the saved token hasn't expired. There's no network call and no second login. It prints what it finds inside:

$ bjs whoami
Logged in as:
  Email: you@example.com
  Name: Your Name

If it says Not logged in. instead, that's the one account problem you'll ever hit. A month from now, or on a new machine, the tokens will have expired. The fix is always the same. Run bjs login and go through the login again. To end a session on purpose, like on a shared machine, use bjs logout:

bjs logout

That removes the tokens and account info from ~/.bjs/config.json, but it keeps your saved preferences. Login, whoami, and logout are the whole account surface. All of them read from or write to that one file.

What you have now

You have bjs installed, a real session saved to disk, and bjs whoami printing your email. More than that, you know how that session was made. There was a device-code request, a short user codeA short, human-typable code the CLI prints for you to enter on the verification page so the server knows which login to approve. you typed on a page you trust, and a poll loop that kept asking until it collected your identity. Every account command ahead depends on the tokens this login left behind. That includes browsing the catalog, spending credits, downloading an asset, and submitting your own work.

Next, you put that account to use on an empty folder.

Next: Scaffold a Project — one command turns an empty folder into a running BabylonJS game. It first asks two questions that decide the project's shape.