Those users won't have a password. They may not even have a username (I think Steam users can change their user name; not sure how their API handles this when telling you their username; be mindful of this). Ideally you'd use the Steam user ID.
Here's a brief intro to OpenID:
You must be registered to see links
And here's a random website I found that looks to explain the various aspects of OpenID well:
You must be registered to see links
It's been a while since I've had to mess with this, so anyone can feel free to correct me if I'm mistaken, but here's a rough example implementation:
Upon logging in with OpenID, you would create a session for your user. Your user's cookied session will probably contain a session ID that links to a session in your server. That server-sided session would be a key/value map that contains the ID Token (the one that can be used to get an access token).
If memory serves me correctly, the ID Token generally doesn't expire for a sizable amount of time, while the access token expires much faster. The access token verifies with Steam that the ID Token is indeed still valid (I'm not certain, but I imagine you wouldn't be able to get an Access Token via the ID Token if the user, say, changes their Steam password). The Access Token may also let you ping Steam's API for information pertaining to the user.
I imagine that the user in your database would be associated with the logged in steam account, as the ID token (and the access token) can change, but the steam user's ID (assuming they provide you with that) would not change. To log in to their account on your site, they'll log in through OpenID, which will create a cookie-backed session with an ID Token attached to it server-side. If you have long-lasting sessions, you may want to periodically attempt to get an Access Token in order to confirm that their session is still valid, i.e. still appropriately associated with their Steam account.
